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Upcoming USENIX Events 


9th USENIX Systems Administration Conference (LISA J 95) 

September 18-22.1995, Monterey Conference Center, Monterey, CA 
Co-sponsored by USENIX and SAGE, the System Administrators Guild 
Program Chairs: Tina Darmohray, Consultant, and Paul Evans, Synopsys, Inc. 
Pre-registration Savings Deadline: August 25,19% 


USENIX 1996 Technical Conference 

January 22-26,1996, San Diego Marriott Hotel & Marina, San Diego, CA 
Program Chair: Bob Gray, US WEST 

Authors Notified: August 31,1995; Camera-ready Papers Due: November 14,1995 


5th UNIX System Administration, Networking, and Security 
Symposium (SANS V) 

May 13-17,1996, Washington, DC 

Sponsored by FedUNIX, Open Systems Conference Board, and SAGE, the 

System Administrators Guild 

Program Chairs: Rob Kolstad and Michelle Crabb 


10th USENIX Systems Administration Conference (LISA "96) 

September 30 -October4,1996, Chicago Marriott, Chicago, Illinois 
Co-sponsored by USENIX and SAGE, the System Administrators Guild 
Program Chairs: Helen Harrison, SAS Institute; Amy Kreiling, University of 
North Carolina 


2nd USENIX Symposium on Operating Systems Design and 
Implementation (0SDI) 

October 29-November 1,1996, Seattle, Washington 

Co-sponsors (pending) ACM SIG0PS and IEEETC0S 

Program Chairs: Karin Petersen, Xerox PARC; Willy Zwaenepoel, Rice 

University 

Full Papers Due: May 7,1996; Notification to Authors: July 30,1996; Revised 
Papers Due for Shepherding: August 19,1996; Camera-ready Full Papers Due: 
September 16,1996 

6th USENIX UNIX Security Symposium 

Fall 1996, location to be announced 

4th Annual Tcl/Tk Workshop '96 

Dates and location to be announced 


For more information about USENIX and its events, access the USENIX Resource 
Center on the World Wide Web. The URL is http://www.usenix.org. Or you can send 
email to our mailserver at: info@usenix.org. Your message should contain the line: 
send catalog. A catalog will be returned to you. 
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FROM THE EDITOR 


USENIX BOARD OF DIRECTORS 


Dreams Fulfilled 


Fourteen hours after I write this, I’ll be hopping onto an airplane that will take 
me to Boston and thence Amsterdam (the one in the Netherlands). I will spend 
10 days representing the USA as Deputy Director of our USA Computing Olym¬ 
piad, and coach of the official USA team of five to the International Olympiad on 
Informatics (which is like the Math Olympiad or Physics Olympiad, but for 
computer programming). 

I can remember dreaming in high school of working with a team of the best and 
brightest student programmers from around the country. And now it’s happen¬ 
ing. 

Today, I finished typesetting a book for the local historical society (I live to type¬ 
set, you know) and completed the audio (music + voice) portion of the slide 
show to advertise the 1996 National Caving Convention which will be held in 
Colorado. 


And I’m working hard as a high-ranking official in my current company (with 
enough salary to keep me in compact discs and typefaces). And I have a house. 
And friends. And parents whose health is good. And mostly good health for 
myself (if you don’t count eating too much). 

Near as I can tell, I should be the happiest guy on earth. I should be bouncing off 
the walls with happiness. I should be grinning from ear to ear. 

I don’t know why I don’t get up every morning with a sunny disposition and a 
spring in my step. 


I think I’ll work on that next. 


RK 


Online Library on the Web 

Remember! Members are now able to access full papers (ASCII and PostScript) 
from the 1994-1995 USENIX proceedings on the USENIX Resource Center on 
the Web: http:Hwww.usenix.org. 

As each future proceedings is published, we will link the abstracts and full 
papers. If you did not receive your password/membership card via postal mail, 
please contact <office@usenix.org>. 


To communicate directly with the USENIX 
Board of Directors, you may do so by writing to 
<board@ usenix.org>. 

President: 

• Stephen C. Johnson <scj@usenix.org> 

Vice President: 

• Eric Allman <eric@usenix.org> 

Secretary: 

• Lori Grob <grob@usenix.org> 

Treasurer: 

• Rick Adams <rick@usenix.org> 

Directors: 

• Tom Christiansen <tchrist@usenix.org> 

• Dan Geer <geer@usenix.org> 

• Andrew Hume <andrew@usenix.org> 

• Greg Rose <ggr@usenix.org> 

Executive Director: 

• El lie Young <ellie@usenix.org> 

CONFERENCES & SYMPOSIA 

• Judith F. DesHamais 
Conference Coordinator 
USENIX Conference Office 
22672 Lambert Street, Suite 613 
Lake Forest, CA 92630 
Telephone: 714/588-8649 
FAX: 714/588-9706 

Email: <conference@usenix.org> 

• Peter Mui/Zanna Knight 
Vendor Displays 

Email: <display@usenix.org> 

• Daniel V. Klein 
Tutorial Coordinator 
Telephone: 412/421-2332 
Email: <dvk@usenix.org> 

WWW URL: http://wwwMsenix.org 

Automatic Information Server 

To receive information electronically about 
upcoming USENIX symposia & conferences, 
finger <info@usenix.org> and you will be 
directed to the catalog which outlines all avail¬ 
able information about USENIX services. 

Supporting Members 
ANDATACO 

Frame Technology Corporation 

Graph On Corporation 

Matsushita Electric Industrial Co., Ltd. 

Sun Microsystems, Inc., SunSoft Network 
Products 

Tandem Computers, Inc. 

UUNET Technologies, Inc. 

Sybase, Inc. 

The closing dates for the next two 
issues of;login: are August 16 and 
October 11,1995. 
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OPINION 


“Opinion’' is an occasional column 
published in this space. If you feel 
strongly about a subject that would 
be of interest to our community, we 
will air it here. Please send your arti¬ 
cle to <login@usenix.org>. 


Thoughts on the Net 

by Jeff Bacon 
< bacon@mtu. edu > 

The Net is a pretty amazing place. It’s perhaps the first medium ever by which so 
many people from so many different places and cultures can interact with each 
other with such ease and speed. It's also perhaps the first place ever where the 
ideal behind the First Amendment has truly taken shape. 

Critic A. J. Liebling has said, “In America, freedom of the press is largely 
reserved for those who own one.” Being the cynic critic that I am. I’d say it isn’t 
even that simple - someone has to put paper in the press, distribute the results, 
and get people to read it. 

Access to the Net, on the other hand, carries a much lower price tag; all it takes 
is a cheap terminal and a cheap modem. An article in Wired illustrates how it can 
be done for a mere $200. Basic service can normally be had for less than your 
monthly dose of cable TV. 

For that small price, Joe or Jane American can blab to the world on whatever 
subject they might wish to address, with a high likelihood that the missive will 
be read by at least some significant portion of the population. Universal commu¬ 
nications, with no editor. A chance for everyone to take their opinion and pub¬ 
lish it to the world, to debate and defend their ideas in an open forum, all at no 
cost (other than the connect time). No doubt this irks the traditional media to no 
end. I like that. I think Thomas Paine and Thomas Jefferson would approve as 
well. 


As the hometown electronic coffeehouse, the BBS of course was there first. Cer¬ 
tainly FidoNet deserves mention as the first really effective stab at linking all 
those disparate BBS forums into a greater whole through which people could 
communicate. Indeed, FidoNet lives on today - though, just as Usenet News 
shifted from being transported via UUCP to Intemet-based connections, the 
Internet has become the medium through which many FidoNet nodes connect. 
The Internet grows and assimilates, though hopefully not with the Borg’s single- 
mindedness or sinister ends. Not bad for a DARPA project nailed together by a 
small (well, not that small) Massachusetts consulting firm and some geeks at UC 
Berkeley. 

The amazing thing to me is that the Net has survived so long without being cen¬ 
sored by one group or another, being regulated to death, or becoming dominated 
by a couple of megacorps and turned into a huge money-making video game. I 
think up until this point, the perception that the Internet was a commercially use¬ 
less realm of geeks and hackers has saved the net from notice by Greater Pow¬ 
ers. 

Unfortunately, it’s becoming obvious to all but the blind and deaf that “thar’s 
gold in dem thar wires,” and the Internet is starting to draw the masses. We now 
have an electronically-aware Veep tapping out Q&As on CompuServe, an elec- 
tronically-clueless senator trying to legislate Internet morality, Baby Bells fight¬ 
ing with cable-TV magnates for the opportunity to build infobahn onramps to 
everyone’s house, a government agency or three that wanted us to use their 
encryption standard so they could read everything, and a software monop ... um 
. . . company that wants to build a new Internet in its own image. 

One recent development really worries me. We’ve been hearing on the tradi¬ 
tional media about how neo-Nazi groups and such are communicating via the 
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Internet. Gee, of course they do. They also use phones and 
the US Postal Service, just like everyone else does. Is any¬ 
one really surprised? Of course not. Does this mean we 
should start censoring the US mail? Of course not. Yet this 
sort of thing is being used to cast the Internet in a bad light, 
with the implication that something should be done. 

I know, I know, I’m just being paranoid, right? No, not 
really, I’m just not an entirely trusting soul. And the Inter¬ 
net doesn’t really have a PR agent to defend itself. 

Fortunately, this very fact - that the Internet doesn’t have a 
press agent - is actually a good sign to why the Internet 
electronic coffeehouse concept is likely to survive this next 
phase of its growth, as it gains the attention of the greater 
powers of the world. Why? For the Internet to have a press 
agent, it’d have to have some sort of administrative exist¬ 
ence. But it doesn’t, other than the loose cabal of the Inter¬ 
net Society and the IETF that acts as custodian of the 
standards. The Internet, very simply, doesn’t really exist as 
a tangible entity. It’s a concept. 

In times past, the Internet was based around a core back¬ 
bone - first the ARPANet, then the NSFNet. But it’s no 
longer really needed now - the Internet has taken a life of 
its own. The major service providers all have their own 
cross-country backbones, and they all interconnect. They 
have to. Their business is connectivity; if they don’t pro¬ 
vide routes to everywhere, they aren’t providing what the 
customers want. 

Even so, that’s all just wire. The Internet concept tran¬ 
scends that. It’s the idea of linking computers together for 
the purpose of linking people together, in ways formerly 
impossible and only dreamed of. It doesn’t really take a 
huge national network, as FidoNet and Usenet proved; all it 
takes is some phone lines and users willing to talk. Heck, it 
doesn’t even take phone lines - there are plenty of wireless 
options available. The Internet just proves that it can work 
on the super-economy-pack scale. 

People know now what’s possible - we’ve finally found a 
way to communicate amongst ourselves and even between 
countries quickly, cheaply, and effectively. Someone sug¬ 
gested that that was the true spirit behind the First Amend¬ 
ment and I’m inclined to agree. Will we give it up that 
easily? I’d hope not. 


Gnu and Solaris 

by John Sechrest 

< jasmic!sechrest@CS. OR ST. ED U> 

The Gnu project, to provide a freely distributable UNIX sys¬ 
tem, has had a significant impact on the commercial world. 


Often this impact has been unanticipated. NeXT uses an 
altered Gnu compiler to provide Objective-C for their com¬ 
puter. Many vendors distribute pieces of Gnu programs as 
part of the initial environment. 

I believe that Gnu accelerated the rate at which 4.X BSD has 
become freely distributable and has accelerated the rate that 
4.3 versions have been available commercially for 386 sys¬ 
tems. I believe it has retarded the rate at which System V 
systems have adopted 4.3 utilities. Those people who cared 
for 4.3 services, but had System V machines can soothe 
their problems with Gnu utilities that have been ported to 
System V. 

With the fervor of someone who has found religion, Sun is 
moving to System V with Solaris 2.0. Many of the people I 
talk to have significant fears about this move. It has been a 
joy to work with Suns because they were 4.3 based; even as 
the System V tools were added. Sun OS 4.X is still signifi¬ 
cantly BSD based, especially in the system administration 
area. While I have not had an opportunity to explore Solaris 
2.0 in detail, reports that I have heard are that the system 
administration structure and many of the tools are fully Sys¬ 
tem V. This frightens a significant number of people. Many 
people that I know are planning a wait-and-see attitude for 
Solaris. If it is as significantly System V as it seems, many 
people are going to hold off converting to Solaris for a long 
time, perhaps years. 

Sun workstations are one of the easiest systems to adminis¬ 
ter. They provide an easy collection of tools which lets you 
manage large numbers of machines with little effort. As net¬ 
works become significantly larger, this is a critical ability. 
Several groups have chosen to stay Sun-only shops, because 
of the 4.3 based environment and ease of administration, 
even though the HP 700 is a faster machine. With the intro¬ 
duction of Solaris 2.0,1 believe Sun has opened up a Pan¬ 
dora’s box. They have broken the hold that they have had. 
Now that Sun will not be BSD based, HP-UX begins to look 
stronger. It would not surprise me if Sun-only shops start 
adding a much wider mixture of systems, because of the 
introduction of Solaris 2.0. 

As I said earlier, the Gnu project has often had unanticipated 
effects on the commercial world. It is possible that the Gnu 
project will provide the tools to make the differences 
between Sun OS 4.X and Solaris 2.0 unimportant. By 
installing the Gnu tools, the underlaying OS may be less in 
evidence. It may be that by installing Gnu programs as a part 
of the regular path, the ebb and flow of the Sun OS migration 
is mitigated. Watching the installation rate for Solaris 2.0 
will be an interesting sport for the next year. Will Solaris 2.0 
drive people to other platforms? Will Gnu software ease the 
pain enough so that people stay in a comfortable environ¬ 
ment? Stay tuned .... Same Gnu Station! Same Gnu Chan¬ 
nel! 
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USENIX Member Benefits 

As a member of the USENIX Association, 

you receive the following benefits: 

• Free subscription to ;login:, technical fea¬ 
tures, system administration tips and tech¬ 
niques, international calendar of events, 
SAGE News, media reviews. Snitch 
Reports from the USENIX representative 
and others on various ANSI, IEEE, and ISO 
standards efforts, and much more 

• Free subscription to Computing Systems, 
the refereed technical quarterly published 
with The MIT Press 

• Access to papers from USENIX Conference 
and Symposia, starting in 1994, via the 
USENIX Online Library on the World Wide 
Web < http:liwww.usenix.org> 

• Discounts on registration fees for the 
annual, multi-topic technical conference, 
the System Administration conference 
(LISA), and the various single-topic sympo¬ 
sia addressing topics such as object-oriented 
technologies, security, operating systems, 
electronic commerce, and mobile comput¬ 
ing - as many as seven technical meetings 
every year 

• Discounts on the purchase of proceedings 
from USENIX conferences and symposia 
and other technical publications 

• Discounts on BSDI products 
BSDI information: 800 800-4BSD 

• Discounts on the five volume set of 4.4 BSD 
manuals plus CD published by O’Reilly & 
Associates and USENIX 

« Savings (10-20%) on selected publications 
from McGraw-Hill, The MIT Press, Pren¬ 
tice Hall, John Wiley & Sons, and O’Reilly 
and Associates 

• Special subscription rates to the periodicals 
The LINUX Journal (Phone: 206 527-3385) 
and Uni Forum Monthly, Uni News, and the 
annual UniForum Open Systems Products 
Directory 

• Right to join SAGE, the System Adminis¬ 
trators Guild 

To become a member or receive information 

regarding your membership status or benefits, 

please contact <oJfice@usenix.org>. 

Phone: 510 528-8649. 


Report on the Fifth 
USENIX UNIX Security 
Symposium 

by Rik Farrow 
< rik@spirit. com > 

The previous security symposium (Santa Clara in 1993) was a little disappoint¬ 
ing. Not that it was bad. It simply fell short of the previous symposium, with 
papers which announced SOCKS and other now familiar tools. It was thought 
that by waiting longer than a year for the next symposium, more exciting work 
would surface. And I believe it did. 

Not that the conference by itself provided all the excitement - just getting to Salt 
Lake City turned into an adventure, with wind gusts rivaling the first hurricane 
of the year. Tractor trailers were blown over along interstates leading west, and 
flights bounced about waiting for the wind to subside enough for safe landings. 
This was on Monday evening, June 5. 

Unseasonably cool weather prevailed, and a few sunburned faces could be seen 
at the conference - people who had visited the ski resorts surrounding Salt Lake 
City, usually closed by May. Not everyone played that day; some attended the 
seminars on UNIX Security (Gene Spafford) and Internet Firewalls (Tina Dar- 
mohray and Marcus Ranum). 

There were several BOFs on Monday night, and I can report on the one I 
attended. Trusted Information Systems has supplied a freely available set of fire¬ 
wall proxies called the Firewall Toolkit (ftp.tis.com/publfirewallsftoolkit ), and 
the BOF was about the future of the toolkit. Fred Avolio, Product Manager for 
TIS’s commercial firewall, presided. Avolio provided a history of the toolkit, and 
solicited suggestions for its continued support. TIS walks a delicate balance, as 
its free software competes with its commercial product. At the same time, 
Avolio and Marcus Ranum, asserted that they felt very strongly about providing 
software with no security-related bugs. 

Suggestions ranged from selling the toolkit and restricting its uploading to regis¬ 
tered users, to selling maintenance contracts. Mike Pearlman, of Rice Univer¬ 
sity, said he couldn’t buy the product outright, but could get the university to pay 
for maintenance. 

Keynote 

Fred Avolio, as program chair, introduced his boss, Steve Walker, the founder of 
TIS. Walker explained how a conference like this so suited him, that he gave up 
wearing ties when he started TIS in his recreation room. He also explained how 
he wound up in security when he transferred from the NS A to DARPA in 1974 
(you’re from NSA, you must know about computer security!). 

Walker’s subject was network security, and he followed a tangled and interesting 
thread getting there. He pointed out that governments came about partially as a 
means for mutual protection - that people, banded together, could organize to 
defend themselves (or attack other groups). Now the world of networking is 
leaving governments behind. As an example, a man traveling through Zaire 
found an Internet connected site in the backcountry, and proceeded to read his 
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email and communicate with his coworkers. It was easier 
for him to reach around the world then to contact the capi¬ 
tal of Zaire. 

“We want to talk to everyone, but we want protection from 
the bad guys. Whenever there’s a threat, from malicious 
hackers or terrorists, we expect protection. The government 
argues that the very tools that we want to use to protect our¬ 
selves, the bad guys will use against us. This is the 
dilemma. We want to have protection, but this protection 
can be used against us.” 

This brings Walker to his thesis, cryptography. He points 
out the terrible contradiction now faced by US users and 
companies: that they can get the same crypto products from 
overseas that they are forbidden to export from the US. 
There are two issues here: one, that encryption is consid¬ 
ered munitions (witness the Phil Zimmermann case), and, 
that encryption can be used by the bad guys. The govern¬ 
ment’s solution to the second problem was the Clipper 
Chip, something that appears to have failed quite misera¬ 
bly. The biggest stumbling block around using Clipper 
focused upon the plan that the Federal Government would 
maintain keys to all encrypted data in a pair of escrow 
accounts. 

It is hard to imagine France, Israel, or Japan permitting the 
US government to hold the keys to their secure transmis¬ 
sions. Walker added that the notion of key escrow is not all 
bad. Any company which uses encryption would be wise to 
keep its own escrow keys, in case an employee quits, goes 
on sabbatical, or just plain forgets his or her key. 

The scheme Walker described is called Commercial Soft¬ 
ware Key Escrow. Each escrow-enabled application would 
register itself with a data recovery center. Then the key 
used to encrypt data would itself be encrypted and travel 
with the data. If the key is lost later, a means to decrypt the 
key, and then use the key to decrypt the data, is provided 
through the data recovery center. The center does not store 
individual keys, but does include a mechanism for recover¬ 
ing the key saved with each file. 

With this scheme, corporations have a method for recover¬ 
ing data (as do individuals who have forgotten their keys). 
Law enforcement can get the keys by subpoenaing the data 
recovery center, a public process. Only the national secu¬ 
rity people get left out - they must publicly request keys, 
and cannot decrypt data transmission without public notice. 

TIS has applied for a patent for this idea, and hopefully, 
their patent won’t be as closely-held as other cryptography 
patents have been. 


Tuesday Morning 

Ira Walker, of SAIC (Science Applications Intemation Cor¬ 
poration), led off with an interesting presentation about 
social engineering. He reported about several contracts. 

SAIC had to test security at remote sites. In each case, they 
had four days to penetrate the site, but were only allowed to 
talk on the telephone, not to directly exploit the remote sys¬ 
tems. 

Hackers are quite adept at this type of intelligence gathering. 
“Social engineering,” a new name for con jobs, is an ancient 
human skill, and Walker showed that even non-hackers, 
without ever visiting the site, dumpster diving, or getting a 
job as a janitor, could have tremendous success. By using 
800 numbers, the group from SAIC probed the target sites, 
working their way up from mail rooms to board rooms. They 
managed to have a corporate telephone directory over¬ 
nighted to them, which provided more data. In general, the 
target company’s employees’ helpfulness worked against 
them. The SAIC group acquired passwords, phone numbers 
for modems, and even had the necessary software for using 
secure modems shipped to them overnight. 

Lessons learned included not providing internal identifiers, 
like employee numbers, or identifying callers by calling 
them back at their proper phone numbers. This was obvi¬ 
ously a chilling exposition for many of the attendees. 

Next, Laurent Joncheray, of Merit Network, Inc., described a 
simple active attack on TCP. A passive attack consists of 
sniffing passwords. Active attacks consist of taking over an 
existing TCP connection. Joncheray described enough of the 
TCP protocol to provide a foundation for active attacks, then 
discussed the two scenarios he used. Both involve desyn¬ 
chronization, getting the client and the server out of sync by 
changing the sequence number at the start of a connection, 
or by sending null data to the server later in the conversation. 
In the paper, he demonstrated the insertion of commands 
into a telnet session after it has been authenticated using 
S/Key, a one-time password scheme. 

Alex Muffett, of Sun Microsystems in jolly olde England, 
presented some ideas about how to go about hacking your 
own network - especially when it’s a big one (30,000 hosts, 
1,200 subnets), with only six security people. Muffett said 
his biggest problem was that most machines were used by 
“peasants” (after introducing his talk using an analogy of a 
kingdom far, far, away). 

AutoHack is a set of shell scripts which Muffett has yet to 
get permission to distribute. He wrote these scripts (and a lit¬ 
tle Perl) because he was bored with manually scanning the 
systems. Although some tools exist, some cost money, while 
others (like SATAN) mainly look for trust relationships. He 
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wanted something which could easily produce reports which 
could be passed onto the “peasants.” 

Muffett presented his solution starting with a very simple 
shell script which explores trust relationships using rsh and 
various user ids. He goes on to explain how it is better to first 
“ping” hosts, so as to not waste time waiting for unrespon¬ 
sive hosts. As he continued to elaborate, he got to his BIG 
POINT: all you need is a framework to drive your probes. 

The paper includes a flowchart describing the current anat¬ 
omy of AutoHack. Questions focused on trying to weasel 
some part of the software (Can I get the banter library?), and 
on how badly this beats up the network (“It does some nice 
things,” said Muffett). 

Tuesday After Lunch 

Dan Geer presented Kerberos with Clocks Adrift, a parable 
about how to deal with unsynchronized clocks and an 
authentication system which relies on secure time synchroni¬ 
zation. As an example of how difficult synchronization can 
be, Geer pointed out that 70% of all PCs are somewhat porta¬ 
ble. Geer’s presentation described a little of the history of 
Kerberos, and how its authentication method works. His 
solution involves taking the time stamp included in pre- 
authentication data and creating a delta between the time 
found encrypted in the packet and the local system’s sense of 
time. 

Pau-Chen Cheng, of the IBM Watson Research Center, spoke 
about Secure IP tunnels under AIX using Modular Key Man¬ 
agement Protocol. The tunnel uses encryption at the IP layer 
to secure communication between hosts, or between fire¬ 
walls. Key management relies on secret keys, key lifetimes, 
cryptography, and nonces (one-time values). In this system, 
communicating pairs share a common master key, and gen¬ 
erate one or more session keys. The master key itself can be 
distributed manually, via key distribution systems, or by 
using public key technologies. Using the master key, each 
side creates an identical session key, which is never trans¬ 
mitted. 

The IP tunnel used is a loadable kernel module, and includes 
a policy engine, which determines when encryption is neces¬ 
sary. Encrypted packets are encapsulated within IP, hiding 
information useful in traffic analysis (but also foiling many 
firewall technologies which examine protocol headers). One 
questioner asked if the keys are stored as plaintext in kernel 
memory. Unfortunately, yes. Another asked if this is avail¬ 
able on other platforms: it is still internal to IBM. 

Another IBM Watson researcher, Chee-Seng Chow, made the 
next presentation. The paper, “Network Randomization Pro¬ 
tocol: A Proactive Pseudo-Random Generator,” revolves 


around the use of pseudo-random numbers. Each server has 
its own engine, and receives updates from other servers 
which are included with the local seed. This results in keep¬ 
ing each server producing truly random numbers, which 
may be used in other algorithms. More information appears 
in the paper, and from ftp:llsoftware.watson.ibm.comlpub! 
security!nrp. As always, online versions of papers may be 
accessed via the USENIX Web server. 

Tuesday Late 

The late afternoon session featured three different methods 
for providing encrypted sessions above the IP layer. Steve 
Bellovin, presenting for Matt Blaze, described the design 
decision which led to encrypting above the transport layer, 
within the application itself. This makes it possible for a 
firewall to perform its work (encryption does not hide 
details such as source address or port). Bellovin pointed out 
that other versions of encrypting telnet currently available. 

The version described is an extension of the BSD telnet. 
Diffic-Hellman key exchange and triple DES are used, with 
Cipher Feedback Mode. CFM turned out to be important, 
because telnet’s own processing sometimes results in 
dropped characters, temporary desynchronizing the stream. 
CFM re-syncs after eight characters, while still providing 
security against controlled changes by an active attacker. 
This version also includes esm, encrypted session manager, 
which permits encrypted session between hosts even when 
the modified telnet is not used (esm provides the encryption 
layer). 

David Vincengetti, of CERT Italy, went next. He described 
STEL, another encrypting telnet. STEL differs from the pre¬ 
vious version in supporting several encryption methods 
(DES, 3DES, and IDEA), mutual authentication, and several 
methods for providing authentication (UNIX passwords. 
Secure ID and S/Key). An S/Key generator is included in 
the telnet client, available by using the telnet escape. Like 
Blaze’s design, CFM is used during the session (Cipher 
Block Chaining is used during a modified Diffie-Hellman 
key exchange). The software, created because of the 
increase in sniffing attacks, will be available soon (dealing 
with licensing problems now), from ftp.dsi.unimi.it!pub! 
security!cert-itlstel.tar.gz. When Vincengetti announced 
that Italy had no export restrictions on the software (he 
checked), there was loud applause. 

Gene Kim, of the University of Arizona, presented a mech¬ 
anism for secure rlogin. In this scheme, encryption occurs 
between the transport and the IP layer by adding three 
optional layers. The solution is not publicly available cur¬ 
rently, because of source code restrictions, but should be 
distributable with the advent of IPv6. A policy engine, an 
encryption module, and a key manager make up the three 
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layers. MD5 is used to authenticate each packet, preventing 
a man-in-the-middle attack. The rlogin server is modified, 
and additional fields may be present in . rhosts files 
(attributes for authentication and privacy). 

Tuesday BOFs 

I managed to attend two BOFs, the first hosted by CERT. I 
took notes during this BOF, and posted them to the Firewalls 
mailing list. Postings are archived at ftp.greatcircle.com, 
look for Firewalls V4, #351. In brief, Ed DeHart of CERT 
suggested that people use sendmail 8.6.10 at least (8.6.12 is 
the latest), and mentioned that the maintainer of IDA send¬ 
mail has suggested that IDA users migrate to sendmail 
8.6.12. DeHart also cautioned users of the NCSA Web server 
to use version 1.4.1, and to enable secure_log when 
building the server. 

Jim Ellis of CERT announced that sniffing attacks are still 
VERY common, and Suns are still the platforms of choice 
(a Solaris sniffer too). IP source address spoofing is on the 
rise. Steve Bellovin described this attack, and the standard 
defense, using topological information to configure your 
routers to drop packets with spoofed addresses. 

Brent Chapman described the NT Sniper Bug. Some ver¬ 
sions of NT, when combined with certain Ethernet cards, 
pick out random packets not addressed to the server and 
issue ICMP host unreachable packets, killing someone else’s 
connection. 

The next BOF was the traditional Firewalls BOF, chaired by 
Fred Avolio, with Brent Chapman, Marcus Ranum, Steve 
Bellovin, and Bill Cheswick acting as panelists. Once again, 
details appear in the Firewalls archives. Questions dealt 
with issues of firewall performance, setting policies, internal 
firewalls, firewall management, IPv6 and firewalls, doing 
away with firewalls (replacing all your current applications 
with secure ones), and interesting Internet services (the 
Michigan Weather Server which wants to connect to your X 
server). 

Wednesday Morning 

The morning began (too early) with a talk by Toshira Taka- 
hashi on File-Based Network Collaborations, describing a 
general purpose tool for cooperative work that includes bet¬ 
ter security. The second presentation was by Brian Kahn of 
MITRE who presented a new mechanism for permitting the 
“safe” use of the X Window system across a firewall. The 
software, called X gate, understands X wire protocol, and 
acts as a proxy server which disallows “dangerous behav¬ 
ior,” like capturing keystrokes or reading other client win¬ 
dow’s resources. One person asked if anything is being done 
about improving authentication; there isn’t. 


Andrew Molitor presented an architecture for Advance 
Packet Filtering. Molitor, working for Network Systems (a 
router manufacturer), has devised a simple packet filtering 
language which should make it easier to turn access control 
policy into filtering rules. He describes the language, and 
compared it to another well-known packet filter syntax. The 
language includes a compiler and a tool to help verify the 
functioning of each filter. Filters can be placed at five differ¬ 
ent logical locations within the packet stream. Someone 
asked if the language includes the notion of state, like the 
Firewall-1 product, and currently it does not. 

Wednesday Afternoon 

The afternoon session included two talks about Domain 
Type Enforcement, the latest thing in creating secure operat¬ 
ing systems. The first talk was on TIS’s version, and 
described a type enforcement mechanism which includes 
inheritance. Files inherit properties from parent directories, 
and processes inherit properties from parent processes. 
Instead of the access control schemes familiar in UNIX sys¬ 
tems, Domain Type Enforcement associates processes with 
the files it may access, providing much finer grained control. 
The TIS version includes secure networking extensions in IP 
options. 

Spencer Minear, of Secure Computing Corporation, who 
describes himself as a mathematician who had once worked 
on flight control software, and considers himself equally 
paranoid when designing security software, discussed a 
mandatory access control scheme hosted on MACH. A pol¬ 
icy server acts as “mother” and controls what can be done. 
Because MACH is based on IPC, this presents a centralized 
mechanism for providing complete control over applica¬ 
tions’ access to resources. For more information about the 
software, send mail to dtos-request@sctc.com. 

Andy Adamson, of the University of Michigan described a 
single login for NetWare and Kerberos. The University of 
Michigan has over 70,000 user accounts, and having a sin¬ 
gle password for both UNIX systems (using Kerberos IV) 
and NetWare is highly desirable for ease of administration 
and use. It was a good paper (and talk) about the issues of 
single sign-on done securely, how NetWare authentication 
works in version 4.x, and how to integrate it with Kerberos. 

The next two papers described one-time password (OTP) 
designs. Aviel Rubin, of Bellcore, described a more secure 
method (compared to S/Key) for creating OTP’s in software. 
Dan McDonald of the US Naval Research Laboratory 
describes OPIE, an enhancement to S/Key which includes 
improvements in portability, a resuable library, and login 
and ftp servers. OPIE is available from ftp.nrl.navy.millpub 
I securityl nrl-opie. 

Vidar Vetland talked about a tool for extracting reports from 
log files. At issue was a method for creating human readable 
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reports without creating temporary files, modifying the orig¬ 
inal trace files (logs), and having the capability to reproduce 
the results. The extraction tool was built while creating evi¬ 
dence for the prosecution of a real break-in case in Milan. 

Steven Bellovin took to the podium again, this time to 
present a long delayed paper describing attacking systems 
using the Domain Name System. This paper was originally 
written in 1990, but not published until recently. What’s 
changed? Hacker tools have been found which use the tech¬ 
niques described in the paper. Essentially, it is possible to 
have DNS lie if you control the server. It is also possible to 
contaminate a DNS cache by including extra records or by 
sending bogus packets. Paul Vixie’s paper, which followed, 
describes efforts underway to improve the security of DNS. 

The last paper was by James Galvin on an enhancement to 
MIME which combines PEM’s (Privacy Enhanced Mail) 
security features into a single package called MOSS (MIME 
Object Security Services). 

As a side note, I just got my copy of Avolio and Vixie’s 
Sendmail Theory and Practice (Digital Press). Unlike the 
O’Reilly tome, this thin book (262 pages) focuses on the 
authors’ experiences using sendmail in very large sites (they 
both previously worked for DEC). Philosophy and sugges¬ 
tions pepper the text, yet it quickly gets to the point of 
describing essential configuration information used by send¬ 
mail, albeit for the pre-8.6 version, and still relevant today. 

USENIX and 

the City Space Project 

by Zane Vella 
<zane@well.com> 

Earlier this year, in conjunction with Silicon Graphics Inc., 
USENIX sponsored an educational Internet and graphics 
project for young developers called CitySpace. Under the 
direction of Coco Conn and Zane Vella, the CitySpace 
Project is an international networking project which invites 
young people from across the Internet to construct and 
explore a virtual city environment. 

USENIX support made possible a six week public exhibition 
and workshop program at the Exploratorium in San Fran¬ 
cisco, in conjunction with a highly publicized special exhibi¬ 
tion at the Exploratorium called the MultiMedia Playground 
‘95. This installation consisted of an ONYX-supercomputer 
powered interactive theater in which visitors were able to 
navigate within the virtual city, as well as construct new 
buildings, vehicles, characters, and other creations. 


From the CitySpace exhibit at the Exploratorium and a 
simultaneous CitySpace exhibit at the Ontario Science Cen¬ 
tre in Toronto, Canada used an IP connection to share 
graphic updates to the CitySpace environment as well as real 
time position, rotation, and direction information for repre¬ 
sentation of character movement within the environment. An 
open text stream between the two sites, superimposed above 
the graphic display, enabled visitors at either exhibit to inter¬ 
act with each other and to explore the CitySpace environ¬ 
ment simultaneously. 

Contributions to the environment via FTP were solicited on 
several educational mailing lists and involved teachers, stu¬ 
dents, families, and afterschool groups from Arizona, Cali¬ 
fornia, Florida, Hawaii, Massachusetts, New York, Oregon, 
Texas, Australia, England, and Germany. Regular transmis¬ 
sions using CU-SeeMe video conferencing software and out¬ 
put to the CitySpace WWW site enabled remote participants 
to get visual feedback on developments within the environ¬ 
ment. 

Onsite at the Exploratorium, twenty-four young developers 
between the ages of 12 and 18 gained hands-on experience 
with three-dimensional modeling tools including MultiGen 
and Softimage, internetworking procedures, several varieties 
of the UNIX operating system, and local area network trou¬ 
bleshooting. Networking and model building workshops 
throughout the exhibition introduced approximately 4,000 
visitors to the fundamentals of Internet communications and 
computer graphics. 

The entire CitySpace Project team and the Director of the 
Exploratorium’s MultiMedia Playground Exhibition extend 
their gratitude to both the USENIX Board of Directors and 
members for making the exhibition and workshop series 
possible. More information about the CitySpace project is 
available at http:llcityspace.org or by telephone at 
415-824-3636. The Exploratorium is online at 
http: II www.exploratorium.edu. 


Community News 

Andrew Hume <andrew@plan9.att.com> writes: Recently 
my brother (David Hume) led an expedition to climb Makalu 
(8451m = 27,800ft), the fifth highest mountain in the world, 
situated in Nepal about 13 miles from Everest. 

On May 8, he and another climber reached the summit, 
becoming the first Australians to do so. Unfortunately, on the 
way down at about 8100m (26,600ft), David fell about 800m 
(2,500ft) and has been missing since. Given the altitude and 
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the severe conditions since his fall, he is presumed dead; 
search and rescue operations have failed to locate his body. 

Unknown to David, while he was in Nepal, the University 
of New South Wales awarded him his Ph.D. in computer 
science. 

His life was tragically short at 34 years, but it shone brightly 
and he died doing what he loved. He is survived by Deb, his 
wife, and will be missed greatly by friends and family. A 
memorial service was held in Sydney on June 5. 

Congratulations to Rick Adams and Donnalyn Frey! Donna- 
lyn gave birth to their second son, Eric. Baby’s full name: 
Eric Brian Adams; DOB: 4/23/95 at 5:09AM; weight: 6 lbs. 
10 oz. 

Congratulations to Jay Lepreau who tied the knot with 
Caroline this June! 

USENIX 1996 
Technical Conference 

January 22-26,1996 
San Diego, CA 

The 1996 USENIX Technical Conference will present origi¬ 
nal and innovative papers about the applications, architec¬ 
ture, implementation, and performance of modem 
computing systems. 

A major focus of this conference is operating systems prac¬ 
tice and experience. The papers to be published and pre¬ 
sented will describe original work and results in the design, 
implementation, and use of modem operating systems. 

Conference Schedule Overview 

Pre-registration materials available: October 1995 


Program Committee 

Robert Gray, Program Chair, US WEST 

Miche Baker-Harvey, Digital Equipment Corporation 

David Black, Open Software Foundation 

Matt Blaze, AT&T Bell Laboratories 

Darrell Long, University of California, Santa Cruz 

John Ousterhout, Sun Microsystems 

Christopher Small, Harvard University 

Jonathan Smith, University of Pennsylvania 

Carl Staelin, Hewlett-Packard 

Brent Welch, Xerox PARC 

Tutorials 

On Monday and Tuesday, you may attend intensive, immedi¬ 
ately practical tutorials on topics essential to the use, develop¬ 
ment, and administration of UNIX and UNIX-like operating 
systems, windowing systems, networks, advanced program¬ 
ming languages, and related technologies. Our well-respected 
program offers you both introductory and advanced courses, 
presented by skilled instructors who are hands-on experts in 
their topic areas. 

Conference Program & Registration Information 

Watch comp.org.usenix, our Website < http:liwww.usenix.org> 
and the next issue of this newsletter for the full program. 

Materials containing all details of the technical sessions and 
tutorial program, conference registration, hotel and airfare dis¬ 
counts, and reservation information will be available in Octo¬ 
ber 1995. Note: Everyone who is a member receives the 
information. 


Tutorials: January 22-23,1996 
Technical Sessions: January 24-26, 1996 
Birds-of-a-Feather Sessions: January 23-25,1996 
USENIX Reception: January 24, 1996 
Vendor Display: January 24-25,1996 
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SAGE, the System Administrators Guild, 
is dedicated to the advancement and recogni¬ 
tion of system administration as a profes¬ 
sion. In just two years, SAGE’s membership 
has increased steadily, and there is growing 
recognition of SAGE as a representative in 
system administration issues. SAGE brings 
together system and network administrators 
for: 

• professional and technical development, 

• sharing of problems and solutions, 

• communicating with users, manage¬ 
ment, and vendors on system adminis¬ 
tration topics. 

SAGE News Editor 

• Tina M. Darmohray 
<tmd@usenix.org> 

SAGE Board of Directors 

• Elizabeth D. Zwicky, President 
<Dvicky@usenix.org> 

• Hal MiUer, Secretary 
<halm@usenix.org > 

• Pat Wdson, Treasurer 
<paw@usenix.org> 

• Kim Camcv 
<kim@uscnix. org > 

• Paul Evans 
<plt@usenix.org> 

• Bryan McDonald 

<bi gmac@usen ix. org> 

• Paul Moriarty 
<pmm@usenix.org> 

SAGE Working Groups 


Group 

sage-certify 

sage-edu 

sage-ethics 

sage-jobs 

sage-locals 

sage-online 

sage-policies 


Chair 
A rch Mott 
Ron Hall 
Hal Miller 
Tina Darmohray 
Rene Gobeyn 
Mark Verber 
Lee Damon 


You CAN CONTACT THESE GROUPS VIA 
EMAIL AT 

<their-name@usenix.org> for example, 
<sage-certify@usenix.org>. 


SAGE Discussion Groups 

sage-security 

sage-managers 

sage-outreach 

sage-pt 

sage-solo 


SAGE Online Services 

Email server: 
majordomo@usenix. org 


FTP server: 
ftp.sage, usenix. org 

WWW URL: 

http:llwww.sage.usenix.org 

SAGE Supporting Members 

Enterprise Systems Management Corp 
Great Circle Associates 




THE SYSTEM ADMINISTRATORS GUILD 

NEWS 


Somewhere in the Middle 
of Nowhere 

by Tina M. Darmohray 
<tmd@usenix.org> 

If you’ve never been to California, you may have the wrong picture of the way 
most of California looks. If you think about how much agriculture California 
supports, you probably have a pretty accurate idea of most of the landscape. If, 
however, you envision the skyline of San Francisco or the courtroom in Los 
Angeles, then you probably aren’t thinking about the way most of California 
actually looks. 

A non-native Californian would find it difficult to understand why I dreaded the 
following experience: I was asked to install a firewall in a town in the heart of 
the central valley of California. What bothered me was that I was being asked to 
go to the middle of NOWHERE. What I mean by this is that there is no jet ser¬ 
vice to most towns in the Central Valley and there are no airports with jet service 
within two hours driving distance. In fact, the most direct route to most destina¬ 
tions in the Central Valley is a lone highway. Interstate 5, which rifles through 
miles of flat agricultural land and which boasts a minimum average speed of 
about 80 mph (which keeps the interest level up). 

To mitigate what I saw as dim prospects for a day of high cultural value, I talked 
a friend into going with me. I got up at 4:45 a.m. and called my friend to make 
sure that he was starting the process of getting out of bed. I picked him up at 
5:30 and we headed for 1-5 and the long trip ahead. I figured out the cruise con¬ 
trol settings and we ran along at a conservative 74 mph. We arrived at our desti¬ 
nation at 9:15 a.m. We drove through the local hamburger stand and purchased a 
Mac-breakfast on our way to the customer site. 

Neither of us had high hopes as we pulled up to the address we were given on 
19th street. The building was older, as most were on this street. It was a two- 
story brick structure with a daylight basement. The plaque on the front of the 
building said that it was a registered historical landmark, the executive offices of 
Standard Oil of California, built in 1917. (Big deal, we’ve all seen these kind of 
plaques before.) What it didn’t say was that there was a plaque inside which told 
that the building had been almost completely destroyed in 1990 and it had since 
been very carefully restored by the current occupant. Inside, it was no less than 
breathtaking! Inlaid tile floors throughout, carefully color-coordinated custom 
runners, gorgeous oak mouldings, and an original oak banister staircase (retro¬ 
fitted for wheel-chair access). Even the “facilities” were done to the nines, with 
period fixtures, marble floors and walls, and elegant wallpaper to set it off. The 
office furniture was custom-made oak, designed to accommodate the computers, 
but not to detract from the overall decor of the interior. The old vaults in the 
walls were painted an oxidized-bronze green and trimmed with gold scroll 
designs; these served as the stock storage areas. 

We were enthusiastically greeted as we walked into the door of this palatial 
office facility. The staff was decked in casual sportswear; many were dressed in 
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shorts, some wore shoes, others didn’t. Lunch was catered, 
and apparently is, each day. The previously mentioned day¬ 
light basement turned out to be a workout room complete 
with batter’s cage, weights, piped-in tunes, trainer, and mas¬ 
seuse on staff! The machine room was neat, organized, and 
stocked with multiple pieces of all the things that a network 
administrator would need in a pinch (gender benders, extra 
cables, etc.), stored and labelled in easy-to-identify bins. 

Turns out these folks have a track record in the software 
products area and are branching out to become an ISP, hence 
their desire for the firewall. The president of the company 
was one of the guys in shorts. The people were friendly and 
really easy to work with. They were accommodating and 
made us feel like “one of the crew” immediately. 

The install went ‘til around 6 p.m. It was going to be pretty 
late before we got back, given the drive. I’m not much for 
fun diversions when I have the end of the day in sight. I was 
voting for a Mac-dinner, but my cohort was opting for going 
along with our hosts’ dinner offer. They basically insisted, 
so I relented and we walked two blocks to a local haunt. The 
first step in the door made me jump a bit, since, as I stepped 
down, there was a loud crunching sound (and I envisioned a 
large dark beetle, or similar non-appetizing critter). Another 
step required that I look down and see. The tiled floor was 
covered with peanut shells that the clientele had been mer¬ 
rily discarding there. All the tables had unshelled peanuts 
on them, so I got a chance to “do as the Romans do.” It was 
a completely freeing experience to participate in something 
we’re all scolded for from high-chairs forward; I really got a 
kick out of it. 

Before leaving, we were given company tee-shirts to 
remember our day by. On our way out of town I found 
myself wondering how we’d ever forget that place and the 
people there. The experience had been like finding an oasis 
in the middle of a desert. What we had been dreading at the 
outset turned out to be a place that was really hard to leave! 
It was inviting to “do work” there. The atmosphere was 
contagious and both of us lamented the distance between 
ourselves and such a wonderful professional environment. 

I hope they make it in their new ISP endeavors. I’d like to 
return. I can’t imagine how their workplace environment 
will develop (maybe they’ll have code replicators?), but I’d 
sure like to experience it! One thing for certain, we should 
all be so lucky to work in such a “nowhere” place! 


Call for Nominees for 
Election to SAGE Board 
of Directors 

by Pat Wilson 
<paw@usenix.org> 

SAGE is accepting nominations for 4 new members of its 
Board of Directors until October 9, at noon, PST. Anyone 
interested in running for the SAGE board should send his or 
her name and telephone number and a brief statement to the 
nominating committee via email at: 

sage-nomcom@usenix.org 

You can also send U.S. Mail to the SAGE Nominating 
Committee care of: 

USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 

The nominating committee will gather the candidates’ 
names and contact each of them before the election takes 
place. 

In this election, directors will be chosen for two-year terms 
(beginning January 1, 1996) and will join returning Board 
members Kim Carney, Bryan McDonald, and Hal Miller 
(elected last year to two-year terms which began Jan 1, 
1995). The SAGE Board chooses its own officers after each 
general election (every year). At the USENIX LISA Confer¬ 
ence, to be held September 18-22,1995 in Monterey, CA, 
there will be a candidates’ forum to enable candidates to 
introduce themselves and talk about the issues. Prospective 
board members unable to attend the LISA conference will be 
able to submit a position paper to this forum. All candidates 
will be expected to respond for publication to a set of ques¬ 
tions presented by the Nominating Committee. There will, 
in addition, be an on-line forum (most likely an archived 
mailing list) to enable SAGE members to pose questions to 
the nominees. 

The new board will take office in January, 1996, and will 
hold their first meeting at the 1996 USENIX Technical Con¬ 
ference in San Diego, California. Current estimates indicate 
that the new board will have at least 2 face-to-face meetings 
a year, one each at LISA and at the USENIX technical con¬ 
ference, and other meetings via teleconference. 

If you have questions about the nominating process, or what 
Board membership entails, please send mail to 
sage-nomcom@usenix.org or contact a current member of 
the SAGE Board. 
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Some SANS 
Conference Highlights 

by Melissa Metz 
<melissa@columbia.edu> 

With some additional commentary by: 

Christopher J. Calabrese 
<cjc@summit.novell.com> 

Marcel-F ranch Simon 
<mingus@summit.novell.com> 

Joseph Snukis 
<volk@summit.novell.com> 

[Ed. Note: Melissa Metz, et al., attended the recent System 
Administration, Networking and Security (SANS) IV confer¬ 
ence, sponsored by Open System Conference Board and 
SAGE, and held in Washington, DC, April 24-29 . Many 
thanks to Melissa and the crew at Novell. -TMD] 

Keynote 

Katie Hafner, Newsweek Associate Editor and author of 
Cyberpunk: Outlaws and Hackers on the Computer Fron¬ 
tier. 

Katie Hafner’s book has three sections, one of which is 
about Kevin Mitnick. Given recent Mitnick events, her key¬ 
note was very timely. She is writing an article, possibly 
appearing in Esquire, to update the Mitnick story. This will 
also appear as an epilogue in a new edition of Cyberpunk. 
She reiterated part of the original Mitnick story and gave us 
an update on recent events. She has interviewed many of the 
major players in these incidents, and has many insights into 
what drives them (to hack, or to turn each other in). 

A book signing session followed her talk. 

SysAdmin Track 

Goals of System Administration 

by Elizabeth Zwicky , Silicon Graphics 

Or, how to tell if you’re doing a good job. Elizabeth divides 
sites into three levels of support: average (which most sites 
have), acceptable (the least she can stand to work with), and 
excellent, which is rare. She points out that a company has 
certain assets - while its employees are the most important, 
the next most important asset is the data. Backups protect 
the data from accident; security protects the data from inten¬ 
tional harm; and networks allow the data to get to where it 
needs to go. She emphasized the importance of support (an 
official, recognized way to get help), and gave examples of 
the support levels for resource sharing of files and printers, 
maintainability of upgrade paths, to keep things working, 


and backups, security, and networks. Also important are 
human resources issues, i.e., retaining the sysadmins (since 
employees are an asset). 

The 1994 SANS Salary Survey 

presented by Rob Kolstad, BSDI 

The survey results that Rob presented were compiled and 
graphed by Alan Paller of Computer Associates. The top 
25% of sysadmins are making an average of $64k, the next 
25% $49k, then $40k, then $30k. Rob points out that this 
last group must include some part-timers at something like 
$10k. One of the top earners was someone in New York 
City making SI25k, with a beeper on 24-hour call. 29% of 
those surveyed are making between $40k and $50k with 
annual salary increases averaging 5.5%. Sysadmins with 
one year or less experience average $38k, though Rob 
guesses this might reflect recent career switches. 

Part of the survey addressed the issue of how to get better 
raises, for which the most popular answer was to get a new 
employer. One person went so far as to reach the exit inter¬ 
view, where he told them he was leaving to get more money, 
They promptly made him a better offer, one he accepted. 

People Skills for the System Administrator 

by P. David Parks, IEEE 

David discussed various things that ought to be common 
knowledge, but often aren’t. He reminded us to use tact, to 
carefully consider what we are saying in email, and to use 
good manners in our dealings with other people. Common 
problems with email include flaming, and sending mail to 
an entire mailing list instead of one person. He emphasized 
that a sysadmin should try to properly answer questions, 
rather than answering with rhetorical questions, stating that 
they have no time to explain, or giving cryptic answers that 
do not help. 

How SysAdmins Spend their Time 

by Rob Kolstad , BSDI 

Rob re-presented the results of his 1992 survey (seen previ¬ 
ously at the 1993 LISA). It seems we spend most of our time 
dealing with other people, and very little time doing back¬ 
ups. We spend our time doing many different things - plan¬ 
ning, fixing, helping people, etc. He reminded us that read¬ 
ing netnews can be considered personal growth (depending 
on the newsgroup), but that we might re-evaluate the time 
we spend and what we are getting from each newsgroup. 
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How fro Hire Good System Administrators 

by Michelle Crabb, Sterling !NASA Ames. 

In the past, interviewing was usually done by a hiring man¬ 
ager, but these days it is often helpful to leave managers out 
of the loop. Michelle strongly recommends phone inter¬ 
views to do an initial screen of the candidates before invit¬ 
ing them in for lengthy interviews. Once qualified, each 
candidate should be taken on a tour of the facility. Michelle 
gives the candidates a quiz (12 easy questions are included 
in the proceedings and online, see below), testing simple 
skills like writing a ‘‘for” loop in the Bourne shell, or asking 
what five commands the candidate most often uses. At her 
site, they have a number of people interview the candidate 
one-on-one, then get together to discuss the results - this is 
also important for determining if the candidate was taking 
comments from their first interviewer and feeding them 
back to the next interviewer. 

More info is at http:lfwww.nas.nasa.govf NAS 
/RelatedPapersiSANS95I , for all the papers Michelle pre¬ 
sented at SANS IV. 

"Best of SysAdmin Magazine" - Books You 
Really Want to Read 

by Elizabeth (Betty) Zinkum, SysAdmin Magazine 

Betty writes a book column for SysAdmin Magazine , and 
here she lists her favorites. (She had no slides, so all titles 
listed are approximate.) First, she likes Preventing Com¬ 
puter Injury , a Hand Book , published by Ergonomy. The 
author is a pianist, who first became concerned when she 
was at Julliard and her roommate came back from practice 
sessions unable to turn a doorknob - 25% of Julliard stu¬ 
dents suffer from Carpal Tunnel Syndrome. 

Betty also listed common favorites like The UNIX Pro¬ 
gramming Environment , Advanced Programming in the 
Unix Environment , and Nemeth, et al’s Unix System Admin¬ 
istration Handbook. Not surprisingly, she listed several 
O’Reilly books, including Starting UNIX Users , UNIX 
Power Tools (with CD), Essential System Administration , 
System Performance Tuning, TCPIIP Network Administra¬ 
tion , and the new Managing Internet Information Servers. 
She also recommended Peter Salus’s new Casting the Net, a 
history of the Internet. Also mentioned were Cheswick’s 
Firewalls and Internet Security and one or two “dragon 
books” by Bruce and Karen Hunter called Unix Systems 
Advanced Administration and Management Handbook and 
UNIX Networks: a Guide for System Administrators , which 
she found very readable and complete. 


From the Other Side of the Desk: 

Observations of Consumers from Executives 
in the Software and Service Industries 

by Rob Kolstad, BSDI, and E. Scott Menter, Enterprise 
Systems Management. 

Rob and Scott are executives from the Software (BSDI) and 
Service (sys admins) industries, respectively. They attempt 
to give us a reality check on what the goals of vendors are - 
that they are not a personal relationship, but a business one. 
Rob and Scott named types of customers that need to be 
dealt with differently. Early adopters require little training, 
appear in trade magazines, and have a good attitude. “Mid¬ 
dle-of-the-road” types don’t want to fall behind; they read 
the trades with a grain of salt, and usually deal with conser¬ 
vative vendors. Lastly, dinosaurs believe the trades, and like 
to avoid risk. Some companies can belong to different cate¬ 
gories on different days. 

They also discussed what the various players think they’re 
doing. Executives feel they are creating value; they are non¬ 
technical, but look at the big picture and long-term results. 
Sales people feel they are problem solvers; they are the only 
money-makers at the company, and, paradoxically, paradox¬ 
ically, report both to management and to consumers. Engi¬ 
neers see themselves as problem solvers who create the 
product; they take the short view. Those in support feel they 
are producing satisfaction; they get no respect but are usu¬ 
ally very technical, very focused on each call and they take 
a very short view. Lastly, the consumers’ goal is to improve 
productivity, to stay competitive, and to spend money. 

Most frustration in the vendor/customer relationship comes 
from mismatched expectations, e.g., when the customer for¬ 
gets that the vendor is trying to make money or when the 
vendor exaggerates. 

Recommendations include: looking for volume purchases 
which might require less media or packaging, knowing who 
provides support, knowing your customer ID before calling, 
as well as your configuration, trying to maintain mutual 
respect when you call, expecting to be assisted, not trained, 
and not putting customers on hold. 

Advanced Topics in Perl 

by Tom Christiansen 

Tom told us about Perl 5 - how it differs from Perl 4, how it 
is better, and assorted cool features. He showed a lot of 
examples, and pointed us to ftp:Hftp.cis.ufl.edu/publperl, 
which has most Perl items. He also mentioned 
ftp:Hftp.perl.com}pub!perl, but asked us to be gentle and use 
it sparingly, since it is at the end of a very narrow pipe. 
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Somewhat orthogonal to Perl, Tom recommended we use 
html for forms entry, and pointed us to webstorm.com’s 
pub!peril ext! CGI*, which does CGI programming. 

Perl 5 was a major rewrite. It is “object oriented” (including 
inheritance), and many modules are broken out from the 
main Perl executable to be dynamically loaded. For exam¬ 
ple, there is a Tk package, so Tk programs can now be writ¬ 
ten in Perl instead of Tel. Perl 5 has anonymous functions, 
references (like & in C), transparent access to C code, 
enhanced diagnostics (the -w switch and a sysdiag man 
page), and a lot of documentation (man pages). Multidimen¬ 
sional arrays now work. 

Building an Ethical and Policy Infrastructure 

by Rob Kolstad, BSDI. 

Rob defined “ethics” as an acceptable code of behavior, ver¬ 
sus “law,” a formalized code of behavior. The implicit goal 
of ethics is to keep or create a better society. Rob moderated 
a lively discussion about anonymous remailers. They pro¬ 
vide a sendee in that people can talk about personal issues 
(being molested) or things for which they might be perse¬ 
cuted (alternate life-styles - the favored example being peo¬ 
ple who keep ferrets in states where it is currently illegal). 
However, they pose a problem when it comes to tracking 
down illegal activity, such as the posting of copyrighted 
information or sending threats. Rob asked what we as sys 
admins should do about it. Is the current status okay? 
Should we make it easier to be anonymous, or harder? 
Points people brought up included: an analogy to paper 
mail, which can also be forged or untraceable, citizens 
working to change ferret-owning laws, how useful the Inter¬ 
net is to schools, despite the problems, and harassing phone 
messages. 

Networking 

A History of UNIX and the Internet 

by Peter Salus, Author 

Peter based this talk on his two books: A Quarter-Century 
of UNIX (from 1994) and Casting the Net: The ARPANET, 
the Internet and Beyond, just released. In the late 1950s, the 
government was scared by Russians, so they commissioned 
a report on packet-switching communications between 
computers. The first IMPS (Interface Message Processors) 
were not made until 1967, though in 1969 the first four sites 
were connected - three in California and one in Utah. They 
originally had only 6 bits of address space, for a maximum 
of 63 hosts. 

Peter showed us some of the first RFCs, which were type¬ 
written and some even handwritten, since printers were not 
as readily available as they are today. He also had the first 


network map, consisting of two boxes connected by a single 
line. 

In 1972 a satellite connection was made to Hawaii, while 
UNIX became more and more popular even without official 
support. In 1974 the first UNIX user’s meeting was held at 
Columbia University, hosted by Lou Katz and Reidar Bom- 
holdt with some two dozen attendees. In 1977 the name 
USENIX was adopted, with the statement that “UNIX is a 
trademark” while “USENIX is not a trademark”. 

UNIX and the Internet continued to accelerate, to the point 
where the number of hosts on the Internet has doubled in 
each of the last three years. 

PONG: A Flexible Network Services Monitor¬ 
ing System 

by Helen Harrison, SAS Institute. 

As always, Helen presented a practical solution to a com¬ 
mon sysadmin problem. We all use ping to monitor hosts 
and see if they are up, but ping is insufficient for monitoring 
the services on those hosts. At SAS they wrote pong, a 
modular program which connects to services and sees if 
they are working. Built-in modules include tests of ICMP 
echo (a.k.a. plain-old ping), inetd (via the “echo” service), 
NFS (via a nullRPC call), and AFS. It can be expanded to 
test any service by specifying a short no-op interaction with 
that service. 

Pong reads a configuration file which specifies which ser¬ 
vices to monitor on which hosts, and intervals for detecting 
outage and return to service. This requires tuning to detect 
problems before too many users do, without adding too 
much to system load. Notification is done via logs, mail, 
and xmessages to operations staff. Subsidiary programs 
include pongstat to query the server, and KingPong, a 
graphical interface to pongstat with color-coded buttons - 
yellow if a service was down and is back up, red if a service 
is currently down. 

Pong, including a postscript version of the paper, is avail¬ 
able at ftp: Hwww.sas.com/ outgoing/. 

Performance Monitoring for Network 
Preemptive Maintenance 

by F.B. Motahdi, G.E. Telephone Operations. 

Mr. Motahdi prefaced his talk by pointing out the difference 
between people talking about phone networks and us com¬ 
puter folks (he wore a tie), and apologized if he spoke a dif¬ 
ferent language. His task is to monitor T1 lines, and to 
ensure service reliability by detecting and fixing failures 
before the customer notices. Optimally, they prefer to pre¬ 
vent problems, rather than recover from them. The theory is 
that an intermittent problem becomes a soft failure, and this 
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then becomes a hard failure. So they are working on pattern 
recognition to identify cyclical errors, degrading errors, and 
faults. They are in the initial data collection phase. 

The Netscanner Network Monitoring Tool 

by Jack Stewart , California Institute of Technology 

At CalTech’s Center for Advanced Computational Research, 
they have a unique collection of unusual machines. One of 
them is a Touchstone Delta, with 576 nodes, whose primary 
diagnostic was a lot of lights. They created a program called 
xpartinfo to pictorially show which nodes were free, 
which became heavily used. With more machines added to 
their site, they expanded xpartinfo to Netscanner. 
NetScanner contacts hosts in sequence, and is config¬ 
urable. It monitors file servers, terminal servers, and super¬ 
computers. 

Security 

The Pros and Cons of Vulnerability Information 
Disclosure 

by Gene Spajford, Purdue University 

The talk attempted to answer the question: “You just found a 
new security hole; what do you do?” Possible answers 
include: 

• Keep it secret. 

• Fix it on your own systems only. 

• Report it to a small, trusted group. 

• Report widely, possibly providing exploitation scripts. 

On keeping it secret: 

• The problem is not fixed. 

• Others may get hurt. 

• It may come back to haunt you. 

On reporting it to a small, trusted group: 

• Whom do you trust? 

• How do you know they will fix the problem quickly (if at 
all)? 

• How do you know the fix will be propagated? 


On reporting it widely: 

• The problem may be used against you, and/or against oth¬ 
ers before a fix is widely available. 

• Some may not get/apply the fix even if one is widely avail¬ 
able. This includes organizations with unsupported sys¬ 
tems, insufficient resources, understaffed locations, 
untrained personnel, or turnkey systems. 

• It may hasten vendors toward getting a fix out and that fix 
may not be any good, or it may anger vendors and slow the 
fix. 

• It may help others not get cracked, if they can fix it them¬ 
selves. 

• It may help others find other problems. 

• It allows the testing of published fixes. 

On deciding how much to disclose and when: 

• If the vulnerability is widely known and actually used, 
publicize widely. 

• If not widely known and not actually used, inform the ven¬ 
dors first and publicize later. 

On what should be done differently: 

• Response teams should track attacks and vulnerabilities to 
help answer the decision question. 

• Response teams need to maintain very strong vendor con¬ 
tacts. 

• The issue of whether/how the response teams should be 
held accountable needs to be addressed. 

• Users/administrators must demand better software from 
the vendors and be willing to pay for it. 

• Non-common, proprietary OS’s may be considered to 
avoid vulnerability to known problems. 

• New paradigms are needed for flaw reporting and response 
teams. 

• Resign yourself to the fact that it’s an imperfect world. 
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The Basics of UNIX Vulnerabilities: Case 
Studies and Analyses, or UNIX Security: 
Threats and Solutions 

by Mart Bishop, University of California at Davis 

The talk described classes of software vulnerabilities as 
defined by work done in the ‘70’s, how some famous UNIX 
vulnerabilities fall into them, and how to avoid them in your 
own software. The classes are: 

• Improper choice of initial protection domain (e.g., the net¬ 
work is trusted but insecure). 

• Improper isolation of implementation details (e.g., secu¬ 
rity checks done in the client, not the server, allowing 
alternative clients to be built). 

• Improper change (allows race conditions). 

• Improper naming (allows trojan horses). 

• Improper deallocation or deletion. 

• Improper validation (e.g., programs that can’t deal with 
long input). 

• Improper indivisibility (e.g., the non-atomic mkdir in v7). 

• Improper sequencing (related to improper change). 

• Improper choice of operand or operation. 

Conclusions were: 

• Security vulnerabilities in UNIX can’t be hidden because 
they’re too widely known. 

• The threats can be minimized if we’re aware of the vulner¬ 
abilities. 

• Don’t trust the environment. 

• Don’t forget the past. 

• Don’t forget interaction between sub-systems. 

A Network Security FAQ 
(Frequently Agonizing Quandaries) 

by Marcus Ranum, Trusted Information Systems. 

Marcus offered many quandaries for which he finds no easy 
solutions. However, one easy solution he offers is for execu¬ 
tives who want to hook their most private internal systems 
up to the Internet so they can browse the web - often, they 
can be readily served by getting a plain old public access 
account, unrelated to their office computer. 


Questions include: who can connect to the network? What 
is the security policy? What are the mission critical services, 
and how does this influence the need for security? Often, 
workers suffer from a “get the job done” perspective, with 
no time for security. Marcus finds that some problems have 
different owners, with inconsistent answers - like an IP net¬ 
work behind a firewall, with unprotected modems to the 
internal side. 

BOFs 

SAGE 

We reviewed what SAGE does, including their web site 
http:IIwww.sage.usenix.org/saget. Upcoming booklets (top¬ 
ics to follow their Job Descriptions ) will include legal 
issues for the sysadmin, and site policies. Suggestions for 
what else SAGE should do (including petitions by local 
groups for funds) can be sent to the SAGE Board of Direc¬ 
tors at sage-board@usenix.org. 

Majordomo and Large Email Sites 

This BOF dealt with assorted email administration issues, 
with a lengthy discussion (2.5 hours) of Majordomo, talk 
about POP, and how to administer aliases files. Seemed like 
a BOF that would be popular at many conferences. 

The current developer for Majordomo was present, and told 
us about a number of features that will be available in vl .94 
(currently in alpha testing). It will not slow down as much 
when dealing with a large number of aliases. It will have 
access lists for just about everything. There will be an 
option to prepend the listname (intelligently) to the subject 
of each message being processed. 

Someone runs an autobounce program, that handles mailing 
list recipients who are bouncing their mail. It generates 
“approve-unsubscribe” messages to the list maintained and 
moves the bouncing address to a bouncer list. They will be 
sent regular reminders of the fact that their address bounced. 

One university site has 30,000 users, and they receive 60- 
80,000 messages a day. Sun sold them a package with a 
SparcCenter 1000, Online Disk Suite, and NIS (NIS+7). But 
NIS dies on a host receiving a lot of mail, so they bought an 
HP for their NIS server. 

There was some discussion of listproc. Apparently, it keeps 
track of message IDs and checksums (or perhaps adds an X- 
Listproc: header) to prevent loops. We discussed the “Con¬ 
tent-Length:” header, which can be broken by manipula¬ 
tions like this, causing the message to be unreadable by 
some MUAs. The easiest solution is to remove that header. 
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There is a product called Unameit (or possibly Uname*It) 
which will help manage alias files as well as the rest of the 
“enterprise name space.” Apparently Tivoli’s product (like 
Uname*It?) now works for 3 million users. 

Someone suggested that each alias, in addition to a list of 
mail addresses, should forward all messages to “Ihead -1 » 
counters/aliasname”, in order to keep track of whether the 
list is in use. 

There was rumor of something called APOP which is like 
POP but allows for a pool of mail hubs to service the 
requests. In a similar vein, MX records can be used to spread 
the incoming mail load to a number of hosts. 

There is a package called MLA, mail-list-archiver, which 
generates HTML forms for browsing mail archives. It is 
from the author of flex-fax, and is allegedly available from 
ftp.sgi.com. 

Women 

As usual, the women’s BOF was attended by about a dozen 
women and one token man. The woman who had suggested 
the BOF took a list of names and may start a mailing list. 
She offered to contact SAGE and see if there is previous 
women’s-BOF-info or need for a mailing list or SAGE 
women’s page. We discussed how women get into technical 
positions, many issues common to all system administrators 
(getting more money, appreciation for our work, etc.), and 
took a few informal surveys. We discussed support for 
young women studying science and computers. Apparently 
there is some sort of women’s page at MIT. We also dis¬ 
cussed trouble ticket systems and help desks. 

Perl Practicum: 

The Camel Spins a Web 

by Hal Pomeranz 
< ha l@n e tma rket. com > 

Those of you who have been living under a rock for the last 
twelve months may have missed out on this whole World 
Wide Web thing. Most of you have probably already tried 
your hand at some basic HTML authoring. The most inter¬ 
esting application of Web technology, though, is using the 
Web as an interface to arbitrary data from other sources 
such as databases and system applications. One mechanism 
for creating these interfaces is the Common Gateway Inter¬ 
face, CGI for short. 

CGI Basics 

Simply, a CGI program produces (on the standard output) a 
special header line followed by an arbitrary number of lines 


of output. The HTTP server running on your machine 
invokes your CGI script and feeds the output to the browser 
that requested the page (usually the hardest part of this 
whole equation is learning how to configure your HTTP 
server to execute your file). The CGI program can be written 
in any language you like, but why would you write in any¬ 
thing but Perl? 

Here is a trivial example 
#!/bin/perl 

print "Content-type: text/html\n\n"; 
print «" EOmyPage" ; 

<TITLE>"Hello World!" Page</TITLE> 
<Hl>HELLO WORLD!</Hl> 

EOmyPage 

The first line of the script prints the header information, 
specifying the type of document which follows the header. 
In this case, we are saying that the document is an HTML 
text document. A blank line must follow the header informa¬ 
tion (note the two \ns). The rest of the program is just a 
“here document” which prints a trivial HTML page. If at this 
point you are thinking, “That’s easy!”, you are absolutely 
correct: there is no great mystery to this CGI stuff. 

External Files and Applications 

However, the power of this mechanism cannot be over¬ 
stated. As long as your program produces the correct output 
format, it can be arbitrarily complex. For example, you can 
read from and write to external files: 

#!/bin/perl 

print "Content-type: text/html\n\n"; 

$visitors = 'cat countfile'; 

$visitors++; 

if (open(OUT, "> countfile")) { 
print OUT $visitors; 
close(OUT); 
print «"EOmyPage"; 
<TITLE>Welcome</TITLE> 

Hello visitor number $visitors. 

EOmyPage 

1 

else { 

print "Sorry, an error occurred\n"; 

1 

Be warned that your HTTP server will probably be running 
under some other user ID and will have that user’s access 
rights to files on your system (try to run your servers as a 
user with no privileges, like the “nobody” user - NEVER 
give HTTP servers superuser access). Make sure that what¬ 
ever files you are manipulating have the correct access 
rights. 
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It is almost never a good idea to abort a CGI program in the 
middle of execution. Remember that there is a user on the 
other side of the Internet who is expecting some sort of page 
to be returned by your script. Notice that the script above 
prints an error message if the open () fails rather than call¬ 
ing die( ) as you would usually. 

Also keep in mind that you can manipulate the output of 
other programs from within your Perl script. In the example 
above, we used the UNIX cat program to retrieve the con¬ 
tents of a file, but CGI allows you to effectively extend the 
reach of the Web by making data from other programs 
available to Web browsers. For example, here is a little CGI 
script that gives back ps output from the machine it is run 
on (one could imagine this as part of a suite of remote diag¬ 
nostic tools for a large network): 

#!/bin/perl 

print "Content-type: text/plain\n\n"; 

if (open(PS, "ps -ef |")) { 
while (<PS>) { print; ) 

I 

else { 

print "An error occurred\n"; 

1 

Note that we are using a different Content-type header. 
Plain text is usually displayed by browsers in a fixed-width 
font (Courier) with all whitespace preserved (unlike 
HTML). For those of you familiar with HTML, the output 
usually looks like it has been formatted in the <pre> block. 

You can call just about any program. You could interface 
with other network information services like gopher and 
WAIS, or even NNTP (how about a Web-based threaded 
newsreader?). You could interface with pieces of your com¬ 
pany database and write a company phone book page, or 
allow people to review their benefits via the Web. However, 
think about security before you go off and try to save the 
world with the Web: you may not want everybody in the 
world to have easy access to much of your data. Even the ps 
example above potentially gives away more knowledge to 
people outside your organization than you should be com¬ 
fortable with. 

The CGI Environment 

Before executing your CGI program, your HTTP server will 
set a number of environment variables. The CGI specifica¬ 
tion (http:JIhoohoo.ncsa.uiuc.edu/cgilinterface.html) spells 
out exactly what information is provided, but here is a use¬ 
ful little test program to see for yourself: 

#!/bin/perl 

print "Content-type: text/plain\n\n"; 

foreach $var (sort keys %ENV) { 

print "\$ENV{$var} = '$ENV{$var}'\n"; 

1 


For example, the remote_host and remote_addr vari¬ 
ables give the fully qualified hostname and the IP address of 
the machine that it connecting to your HTTP server. At Net- 
Market we get a lot of “How’d you do that?!?” comments 
because our home page prints a little “Thanks for connect¬ 
ing from $env{ ' remote_host ' }” message. 

The client browser can also send information to your HTTP 
server. Your HTTP server will put this information into your 
CGI program’s environment using variables that are pre¬ 
fixed with HTTP_. In particular, the client will usually pro¬ 
vide an identifying string such as NCSA Mosaic for the 
X Window System/2.4 libwww/2.12 modified in 
the http_oser_agent variable. Unfortunately, there is no 
established format standard for user agent information, so it 
is nearly impossible to build a procedure which can identify 
an arbitrary browser from its user agent information. How¬ 
ever, it is pretty easy to recognize most of the major brows¬ 
ers. 

What good is identifying a browser? Remember that older 
browsers may not support all the latest features of the HTML 
specification. For example, you do not want to send a table 
to NCSA Mosaic 2.4 because the browser cannot format the 
table information, and you would not want to send an image 
map to a text-only browser like Lynx because the user 
would not be able to see the image. 

Processing Forms 

HTML allows you to create pages which allow the user to 
type in information and submit it to your server. Here is a 
simple HTML form: 

<TITLE>Send Us Email!</TITLE> 

We'd love to hear from you. Enter your 
email address and comments in the spaces 
provided and we'll respond as quickly as 
we can!<P> 

<FORM METHOD="POST" 

ACTION="bin/process_form"> 

Your E-mail address<BR> 

CINPUT NAME="email" SIZE=45 
MAXLENGTH=45><BR> 

Your Message<BR> 

cTEXTAREA NAME="comments" ROWS=12 
COLS=4 5></TEXTAREA><P> 

<INPUT TYPE="submit" 

VALUE="Send yourcomments"> 

</FORM> 

The <form ... action=" ... "> tag specifies what 
program the user’s browser should try to call when they 
submit the form information. This form creates a space for 
the user to enter an email address and a free-form text area 
for the user to type in a message. Finally, there is a Send 
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your comments button to allow the user to submit the 
form information. 

When the user punches the Send your comments button, 
the client browser bundles up all the information that the 
user entered in and sends that information to your HTTP 
server along with a request to the server to run the appropri¬ 
ate program from the <form ... ACTION=” ... ">. 
How your program gets the form information depends upon 
the <form method= "..." . . . > tag. In the example form 
above, the form method is POST, which means that the form 
information will be handed to your CGI program on the 
standard input. You will get a blob of data whose length will 
be specified by the content_length environment vari¬ 
able. The easiest way to grab the data is with the read() 
function: 

#!/bin/perl 

read(STDIN,$stuff 
$ENV('CONTENT_LENGTH'}); 

Now you have to break up the data into intelligible pieces. 
The data comes to you in name=value pairs separated by & 
characters. The names for each piece of data are whatever 
you specified in the form using the <. . . name=" . . . 

11 ... > tags: in the example above, the name for the email 
field is email, and the name for the free-form text area is 
comments. The other tricky part is that spaces are con¬ 
verted to + signs and non-alphanumeric characters are gen¬ 
erally converted to %<hex> where <hex> is the ASCII value 
for the character in hexadecimal notation. Typically, the 
beginning of all form processing programs looks like: 

#!/bin/perl 

read(STDIN, $stuff, 

$ENV['CONTENT_LENGTH'}); 

@pairs = split(/\&/, $stuff); 

for (@pairs) [ 

($field, $val) = split(/=/); 

$field =~ s/\+/ /g; 

$field =~ 

s/%(\w\w)/sprintf("%c H , hex($1))/eg; 
$val =~ s/\+/ /g; 

$val =~ 

s/%(\w\w)/sprintf("%c",hex($1))/eg; 
$entries{$field) = $val; 

1 

First, we read the data off the standard input and then break 
it up into a list of name=value pairs. Then we iterate over 
each pair, break the pair apart, and convert the plus signs 
and hexadecimal escapes back to the original characters. Do 
not try to do the substitutions before you split everything up 
because some of the escaped characters may be & or = . 
Convert the + signs to spaces first because some of the 
escaped characters may be + . 


Now that you have parsed out the input into an associative 
array, you can do anything with the information you like. 
You must return a page back to the user, however, as a result 
of their forms submission: 

print "Content-type: text/html\n\n"; 

if (open(MAIL, 

"| /usr/lib/sendmail webmaster”)) 

{ 

print MAIL «''EOdoc"; 

From: The Comments Page <webmaster> 

To: webmaster 
Subject: Comments Mail 

Mail from: $entries{"email"} 

$entries{"comments"} 

EOdoc 

close(MAIL); 

print «"EOpage" ; 

<TITLE>Thanks!</TITLE> 

Thanks for taking the time to send us 
comments!<P> 

We will be responding promptly.<P> 

EOpage 

1 

else { 

print •^’EOpage”; 

<TITLE>Bummer!</TITLE> 

We encountered an error trying to send 
your comments.<P> 

Please send mail to 
<I>webmaster\@netmarket.com</I><P> 

EOpage 

} 

Be VERY careful about what you do with the data you col¬ 
lect from a form: remember that the user can type ANY¬ 
THING into that form and could cause huge amounts of 
havoc if you trust what they type in. Do not ever allow form 
data to be used as part of a command that you execute from 
your script. Notice that I will not even put the user’s email 
address in the From: line of my message because that data 
might be used to generate a sendmail command if the email 
bounces. 

Further Study 

The best way to become familiar with CGI is to start writing 
some CGI programs. You will probably want to install your 
own HTTP server so that you can play around with the con¬ 
figuration. NCSA httpd (available via anonymous FTP from 
ftp.ncsa.uiuc.edu) is free and easy to build and configure, 
though it is not the fastest server in the world. You will also 
want to study the CGI overview 

{http:llhoohoo.ncsa.uiuc.edulcgiioverview.html) 
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and the tips for writing secure CGI scripts 

{http .7/ hoohoo. ncsa . uiuc. edulcgil security, html). 

Sample CGI programs are available all over the Web (NCSA 
has a small archive of examples to get you started). 

Musings About 
Authentication 

by Shawn Instenes 
<shawni@celene.rain.com> 

Securing machines that are to be used to do business over 
the Internet is a difficult task. There are two basic problems; 
both have solutions - but neither has solutions that are stan¬ 
dards. We should fix this. 

The first problem, that of authentication, is not limited to 
computers and networks, but the size of the problem is 
becoming apparent to an ever-growing audience. Tasks 
ranging from cashing a check and using credit, to commerce 
on the Internet, first require one or more parties to identify 
themselves. 

Most services on the Internet authenticate users with a static 
password, which is rapidly becoming close to no authentica¬ 
tion at all, for reasons I’ll get to in a moment. 

There are generally three methods a computer can use to 
determine if you are who you say you are: 

• It can ask you something you should know (what you 
KNOW), 

• It can ask you to prove you are carrying some sort of ID 
(what you HAVE), 

• It can recognize you from your physical characteristics 
(what you ARE). 

Sophisticated systems rely on more than one of these; very 
paranoid systems use all three. 

The first method (what you KNOW) is usually a password, 
or a Personal Identification Number (PIN) such as you 
would use with your bank card. 

The second method (what you HAVE) relies, in general, on 
hand-held authenticators called tokens , which the computer 
can prove you have by asking you questions about it. For 
example, one popular token has a number on it that changes 
every few seconds; the computer, knowing the algorithm 
and parameters that the token uses to generate these num¬ 
bers, can prompt you for the current value, and compare it 


to the result that it calculates for itself. There are other ways 
to prove the possession of a token; the methods vary with 
the token and software you have. 

The third method (what you ARE) usually means biomet¬ 
rics, such as retinal scans, fingerprint readers, and hand 
geometry readers. These are generally too expensive to 
place on your workstations, and furthermore are too clumsy 
to haul around with your laptop. 

“But what’s the authentication problem?” you ask. The cur¬ 
rent problem stems from several decisions made along the 
way, seemingly independent of one another: 

1. We like passwords because tokens are often not at hand, 
and biometrics just give us the willies (“Look into the 
scanner with your remaining eye, please. It was just a 
glitch.”). Both tokens and biometrics are often expen¬ 
sive. 

2. Most networked computers use a broadcast medium to 
communicate with the outside world, such as Ethernet. 

3. Passwords are passed along between the client and the 
verifier in an easily decipherable form. 

4. A good number of governments seem to feel that they 
should be able to read any arbitrary communication, if 
such interception is justified by National Security con¬ 
cerns. 

So here it is: anyone using a password that’s good more than 
once, that traverses a broadcast-based network, is likely 
sending it to an entire LAN; anyone on the LAN could read it 
and use it again later. 

This is not just a theoretical danger: password sniffing is 
becoming epidemic on the Internet. An intruder need only 
get supervisor access on one computer on a subnet, because, 
once a foothold is gained there, any password that traverses 
that subnet is vulnerable. Even if all the other machines are 
A-OK, fully patched, good passwords in place, enforced by 
the password changing program - even so, the game is up 
and the intruder can storm in, because the sole piece of 
information that they use to identify themselves is a pass¬ 
word authenticator. 

This being the case, people who are trying to secure their 
systems nowadays try to fix (or ignore) some of these items. 
They’ll use tokens or biometrics anyway, despite their draw¬ 
backs. They’ll install “smart hubs” or switched Ethernet, 
which are compatible with all the old stuff but limit who can 
listen to a given network conversation. Some will install 
encrypted versions of network services, so they can’t be eas¬ 
ily abused if authentication data is overheard. However, 
because of item four, most workstation vendors ship their 
workstations with operating systems with no encryption 
software whatsoever (other than crypt (3), of course), in 
order to avoid the governmental red tape that applies in their 
country of origin. Therefore, installing your own means 
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you’re not using standard services, so to work with other 
sites who don’t have or won’t install them, you have to fall 
back to the old stuff, which isn’t encrypted (but see the list 
of URLs at the end of the article anyway). 

This segues neatly to the second problem involved in doing 
business over the Internet: privacy. An easy example is 
credit card numbers. You’d like them to be given only to the 
merchants you do business with, right? But what about your 
home address or phone number? I don’t know of anyone 
who’s been trying to make a mailing list or telephone solici¬ 
tation list by snooping traffic on the Internet, but maybe I 
just haven’t looked hard enough. 

We need encryption to solve this. Without it, commerce on 
the Internet has the potential to lose to fraud at least as 
much as the amount that the cellular industry does - and it’s 
one of their primary business expenses. With operating 
costs like that, the appeal of doing business on the Net 
becomes vanishingly small. 

And it’s not just for commerce. If solid, standard authentica¬ 
tion and encryption services were deployed within the Inter¬ 
net, it would be that much harder for an intruder to gain a 
foothold in a network. Moreover, once there, running a 
password sniffing program would gain the intruder none of 
the advantages that crackers enjoy as a “standard” today. 

In summary, the two prominent security problems facing 
the Internet today have been identified. Additionally, possi¬ 
ble solutions have been proposed. The real problem remain¬ 
ing is agreeing on and deploying standard solutions, but it 
may be something other than lack of technology which is 
the barrier to doing so. 

URLs to free authentication- or privacy-enhanced source 
code: 

deslogin: 

ftp:Hftp.uu.nettpublsecurityldesldeslogin-J3.tar.gz 

and: 

SRA Telnet w/SSL: 

ftp:Hpsych.psy. uq.oz.au!pub! Cryp to! SSLapps 
/ SRA-tjh-SSL0.4.tar.gz 

Other SSL-enhanced applications also in: 
ftp:ffpsych.psy, uq. oz. aufpubf Crypto! SSLapps 

STEL (to be released): 

ftp:flftp.dsi.unimi.it!pub!securityf cert-itf stel! 
ftp:Ifftp.dsi.unimi.itfpubfsecuritylcert-itlSTEL.ps 


Free Network 
Management Using Tel 

by John E. Schimmel 
<jes@sgi.com> 

Tel is an embeddable interpreted language which has 
become popular in the systems administration community. 
Because Tel is free and has been ported to most platforms it 
has become widely expanded by various programmers 
worldwide. One useful addition to Tel over the last couple 
of years is a set of commands to fetch and change SNMP 
variables. This article will talk a little about the use of Tel 
with the SNMP extensions to do simple network manage¬ 
ment. 

There are actually several different SNMP extensions avail¬ 
able on the Net. This article will use two of these as exam¬ 
ples: the SNMP extensions that I wrote for Silicon Graphics, 
simply because these are the extensions with which I am 
most familiar, and a set done by Poul-Henning Kamp to the 
CMU SNMP stack which are freely available. The SGI exten¬ 
sions are shipped with Silicon Graphics machines but have 
not been ported anywhere else as yet. The free extensions 
are currently available with the CMU SNMP distribution, or 
with some cute Tel tools including a MIB walker by Subodh 
Nijsure in the Tel archive at ftp: / fftp.aud.alcatel.com: f tclf. 

The Simple Network Management Protocol (SNMP) is a set 
of standards for providing information about entities on the 
net. The information available is arranged in Management 
Information Bases (MIBs). Most vendors will ship an SNMP 
daemon which supports one or more of these MIBs. There is 
one MIB which is required, commonly referred to as MIB2. 
MIB2 replaced an initial set of variables early in the exist¬ 
ence of SNMP. Popular MIBs on vendor machines also 
include the Host Resources MIB, and the Printer MIB. Many 
vendors of network equipment have also added their own 
MIB for information particular to their independent hard¬ 
ware and management systems. Lately it has become popu¬ 
lar to implement other vendors MIBs when possible so that 
their management software will also manage your 
machines, for instance, supporting the HP-UX MIB to be 
more easily manageable by HP’s Open View product. 

These variables are arranged in an ISO naming tree. Most 
interfaces will allow you to alternatively reference a vari¬ 
able using its simple name (like: sysName), its full name 
separated by dots (like: iso.org.dod.intemet.mgmt.mib- 
2.system.sysName), or the numeric equivalent of the full 
name (like: 1.3.6.1.2.1.1.5.0). Each MIB is assigned a subset 
of this tree. 

From Tel you can fetch a variable, fetch the following exist¬ 
ing variable, or set a variable. Using the SGI extensions you 
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would use the commands “snmpget”, “snmpgetnext”, and "snmpset” to do the above. With the free extensions these are all 
done by methods on an open session. First you open a session, which returns a session descriptor on which you can run methods 
“get”, “getnext”, “set”, etc. Both extensions also support commands for getting information about a variable, or fetching an 
entire table of information at a time. 

Given the very simple commands above, and a remote set of information which is already supported by most vendors, you 
should be able to see many things that would be interesting to monitor. You can easily write a simple script that would run in the 
background watching a remote machine and taking action when something fails. Or, perhaps, you might write a script to fetch 
hardware inventory information from a list of machines. 

One of the variables that is available in the standard MIB which would be interesting to monitor would be the number of net¬ 
work errors that occur on an interface. Network errors can be caused by many things, and are in themselves not a cause for 
instant alarm, but they often warn of more serious trouble. The following is a trivial script that fetches the network error vari¬ 
ables from a remote machine every minute or so, and sends mail to the administrator if more than a couple errors occur in that 
time period. 

#!/path/to/tcl/interpreter 
# 

# This is a procedure that will return the number of total output 

# errors on a system. 

# 

proc if_errors {host} { 

# 

# Fetch the information. In the SGI extensions this command will 

# do a SNMP GetNext request in a loop starting at the given variable 

# until it has read all trailing variables. This next 

# line will fetch a column of the network interface table associated 

# with the output errors. If this machine has more that one interface 

# then we get the error count on all interfaces this way. 

# 

if { [catch [set indices \ [snmpgettable $host 1.3.6.1.2.1.2.2.1.20 table]} error] } { 

# 

# There was an error in setting up the SNMP 

# request, or in parsing the response. This 

# should not happen. 

# 

puts stderr "SNMP Failure: $error" 
exit 1 

1 

if { [llength $indices] == 0 } { 
return -1 

} 

set total 0 

foreach index $indices { 

incr total $table($index) 

} 

return $total 

) 


# 

# This script takes one argument. The name of a machine to 

# monitor. The standard interpreter for Tel will split the 

# arguments into a Tel variable named argv. 

# 

if {[llength $argv} < 1 } { 

# 

# Assume localhost. 

# 

set host localhost 
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} else { 

set host [1index $argv 0] 

} 


# 

# The error variable in SNMP is a counter, so we set an initial value. 
ft 

set values($host) [if_errors $host] 

# 

# Loop forever watching this machine. 

# while 1 [ 

set value [if_errors $host] 
ft 

# If we are negative then the lookup failed. 

# 

if { ($value < 0) || ( ( $values($host) - $value) < 0) } { 

exec echo "Failed to contact host $host." | mail sysadmin 
) else ( 

# 

# Complain if there are more than a couple of errors in 
ft a period. 

# 

if { ($values($host) - $value) > 2 } { 

exec echo "More than two network errors on host $host in last minute." 
| mail sysadmin 

} else { 

# 

# Update global status. 

# 

set values($host) $value 

} 

} 


# 

# Wait a little while while before trying again. 

# 

sleep 60 

} 

This is pretty simple minded, and not horribly useful, but given the Tk extensions to Tel it would be rather simple to put a GUI 
around the if_errors procedure above and maybe a couple of others. Instead of sending mail, an icon could change colors or 
a popup window could notify the administrator. 

The sysDesc field out of MIB2 is a description of the machine in question, which usually includes the manufacturer, model num¬ 
ber, and version of the software for the system. These strings can be used to verify that all the machines on your network are 
running the right version of system software, etc. The following is a code fragment from a procedure which parses each of the 
description fields for machines answering SNMP requests in my domain. It uses some routines from extended Tel to make things 
a little simpler. 

case $description in { 

{Silicon*} { 

# Silicon Graphics Systems 

set index [lsearch $description running] 

set os [join [Irange $description 
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\[expr $index+l] [expr [llength $description]-1]] M "] 
set model [join [lrange $description 2 [expr $index-l]] ""] 

keylset record manufacturer SGI 
keylset record model $model 
keylset record os $os 

} 

{RISCos*} [ 

# Mips Systems 

keylset record manufacturer Mips 

keylset record model [join [lrange $description 4 5] " "] 

keylset record os \ [join [list [lindex $description 0] \[lindex $description 2]] " "] 

} 

{*QMIPS*) { 

# Mips Systems pre RISC/os 
keylset record manufacturer Mips 

keylset record model [join [lrange $description 4 5] " "] 
keylset record os \ [join [list [lindex $description 3] \ 

[lindex $description 2]] " "] 

3 

{HP-UX*} { 

# Hewlet Packard Unix Systems 
keylset record manufacturer HP 

keylset record model [lindex $description 4] 

keylset record os \ [join [list [lindex $description 0] \ [lindex $description 2]] " "] 


{HP*} [ 

# Other HP Systems 

keylset record manufacturer HP 
set entries [split $description ,] 
keylset record model [lindex $entries 0} 

keylset record os [join [lrange [lindex $entries 1] 0 \ 

[expr [llength [lindex $entries 1]]-1]] 

3 

[Alantec*} { 

# Alantec Hubs and Routers 
keylset record manufacturer Alantec 

keylset record model \ [join [lrange $description 1 \ 

[expr [llength $description]-1]] " "] 

} 

{*isco*} { 

# Cisco Routers 

set fields [split $description \n] 
if { [string match Cisco* $description] } { 
set software [lindex $fields 1] 

} else { 

set software [lindex $fields 0] 

3 

set index [string last , $software] 
keylset record manufacturer Cisco 
if { $index>0 } { 

keylset record os [string range $software 1 \ [expr $index-l]] 

} 


{Cabletron*} { 

# Newer Cabletron Hubs 

keylset record manufacturer Cabletron 

keylset record os \ [join [lrange $description 1 end] 
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3 

[IRM*] { 

# Cabletron Wiring Hubs 
keylset record manufacturer Cabletron 
keylset record model [lindex $description 0] 
keylset record os \ [join [lrange $description 1 \ 

[expr [llength ^description]-1]] " "] 


[. • .3 

[The editor has chosen to bypass two pages of code here. The full code for the routine is available on the author's machine: 
<http:lfreality.sgi.comlemployees!jes> ] . 

} 

[DSI*} { 

# DSI Concentrators 

keylset record manufacturer DSI 

keylset record model [lrange $description 1 end] 

} 

[XCONNECT*] { 

# Unknown 

keylset record manufacturer XCONNECT 

keylset record model [lindex $description 1] 

keylset record os [join [lrange $description 2 end] M "] 

} 

[default] { 

puts stderr "no expression matches description: $description'' 
set update 0 
} 

) 

Assuming that all the machines you care about support a MIB which includes the process table, such as the HP-UX MIB, you 
could verify that a particular process is running on a system. For instance you may have a license manager that must always be 
running, but does not always start correctly or tends to crash. If you find that it is suddenly not in the process list the adminis¬ 
trator can be notified or the daemon could be restarted. The following is a trivial code fragment which fetches the running pro¬ 
cess names from a remote machine, and searches the list for a given process using the SGI extensions. 

# 

# checkProcess 

# 

# This routine reads the process table from a remote machine and checks 

# for the existence of a particular name. The arguments for this are 

# a list of hosts, and a process name. We return a data field of true 

# or false, and a status message if it does not exist, or we fail to 

# get it. 

# 

proc checkProcess [hosts process] { 

# we must have a process name 
if { [lempty $process] ] { 

puts "checkProcess: must include process name" 
exit 1 

] 


# 

# Lookup SNMP variable in the MIB. 

# 

set oid 1.3.6.1.4.1.11.2.3.1.4.2.1.22 


set result {} 
foreach host $hosts [ 
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set hostresu.lt $host 

if { [catch { set names [snmpgettable $host $oid table] \ } error] ] [ 

lappend hostresult {} 
lappend hostresult \ 

"checkProcess: snmpgettable returns: $error on host $host" 

} else { 

# 

# Look through table for this name. Can be 

# full path or just tail name. 

# (ie: /usr/lib/sendmail or sendmail) 

# 

foreach entry $names { 

set line [lindex $table($entry) 0] 

if { [cequal $line $process] || \ [cequal [file tail $line] $process]] { 
lappend hostresult true 
break 


if { [llength $hostresult] < 2 } { 
lappend hostresult false 
lappend hostresult \ 

"checkProcess: process $process is not running on host $host" 

} 

} 

lappend result $hostresult 

} 

return $result 


In short, a little time invested fetching and building the SNMP extensions to Tel, and learning how to use them, can provide yet 
another tool in the systems administration toolbox. Learning how to use a language like Tel, with its multitude of extensions and 
applications, is an investment well worth the effort. 

Watch this space for more ideas on using Tel for systems administration. 
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A Practical Guide to 
Internationalization, Part I 

by Michael Gschwind 
< mike@vlsivie.tu wien.ac. a(> 

Introduction 

This series discusses topics related to the use of ISO 8859-1 based 8-bit charac¬ 
ter sets. It demonstrates how to use European (Latin American) national char¬ 
acter sets on UNIX-based systems and the Internet. 

If you need to use a character set other than ISO 8859-1, much of what is 
described here will be of interest to you. However, you will need to find appro¬ 
priate fonts for your character set and input mechanisms adapted to your lan¬ 
guage. 

1. History 

In April 1965, the ECMA (European Computer Manufacturer’s Association) 
standardized ECMA-6. This character set is also (and more commonly) known 
under the names of ISO 646, US-ASCII or DIN 66003. 

However, this standard only contained the basic Latin alphabet, with no provi¬ 
sions for national characters in use all across Europe. These characters were 
later added by replacing several special characters from the US-ASCII alphabet 
(such as {[l]}\ etc.). These variants were local to each country and were called 
“national ISO 646 variants.” Portability from one country to another was low, as 
each country had their own national variant, and some of the special characters 
were still needed (such as for programming C), which made this an altogether 
unsatisfying solution. 

In 1981, IBM released the IBM PC with an 8-bit character set, code page 437. 
The order of the characters added was somewhat confusing, to say the least. 
However, in 1982 the first hardware (DEC VT220 and VT240 terminal) using a 
more satisfying character set, the DEC MCS (Multilanguage Character Set) was 
released. 

This character set was very similar to ISO 6937/2, which is essentially equiva¬ 
lent to today’s ISO 8859-1. In March 1985, ECMA standardized ECMA-94, 
which later came to be known as ISO 8859-1 through 8859-4. However, ISO 
8859-1 was officially standardized by ISO only in 1987. 

1987 also saw the release of MS-DOS 3.3 which used Code Page 850. Code 
Page 850 contains all characters from ISO 8859-1, making a loss-free conver¬ 
sion possible. Code Page 819, which was released later, goes one step further, 
as it is fully ISO 8859-1 compliant. 

The ISO 8859-X standard was designed to allow as much interoperability 
between character sets as possible. Thus, all ISO 8859-X character sets are a 
superset of US-ASCII and all character sets will render English text properly. 
Also, there is considerable overlap between several character sets: a text writ¬ 
ten in German using the ISO 8859-1 character set can be correctly rendered in 
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ISO 8859-2, the Eastern European character set, where Ger¬ 
man is the primary foreign language (-3, -4, -9, and -10 sup¬ 
posedly also can display German text without changes). 

While ISO 8859-X was designed for considerable portabil¬ 
ity, texts are still restricted mostly to their character set and 
portability to other cultural areas is a problem. One solution 
is to use a meta-protocol (such as -> MIME) which specifies 
the character set which was used to write a text and which 
causes the correct character set to be used in displaying text. 

A different approach to overloading the character set as 
done in the ISO 8859-X standard (where the locations OxaO 
to Oxff arc used to encode national characters) is to use 
wider characters. This is the approach employed in Unicode 
(which is an encoding of Basic Multilanguage Plane (BMP) 
of ISO/IEC 10646). The downside to this approach is that 
most of the software available today only accepts 8-bit wide 
characters (7-bit if you have bad luck :-(), so the Unicode 
approach is problematic. This 8-bit restriction permeates 
nearly all code in use today, including system software such 
as file systems, process identifiers, etc.! To ease this prob¬ 
lem somewhat, several representations which map Unicode 
characters to a variable length 8-bit based encoding have 
been introduced (this encoding is called UTF-8). More infor¬ 
mation about Unicode can be obtained from URL 
http:Hunicode.org. 

2. An Overview of ISO 8859 

Use the internationally standardized ISO 8859-1 Latin-1 
character set to type accented characters. This character set 
contains all characters necessary to type (Western) Euro¬ 
pean languages. This encoding is also the preferred encod¬ 
ing on the Internet. ISO 8859-X character sets use the 
characters OxaO through Oxff to represent national charac¬ 
ters, while the characters in the 0x20-0x7f range are those 
used in the US-ASCII (ISO 646) character set. Thus, ASCII 
text is a proper subset of all ISO 8859-X character sets. 

The characters 0x80 through 0x9f are earmarked as 
extended control characters, and are not used for encoding 
characters. These characters are not currently used to spec¬ 
ify anything. A practical reason for this is interoperability 
with 7-bit devices (or when the 8th bit gets stripped by 
faulty software). Devices would then interpret the character 
as some control character and put the device in an undefined 
state. (When the 8th bit gets stripped from the characters at 
OxaO to Oxff, a wrong character is represented, but this can¬ 
not change the state of a terminal or other device.) 

This character set is also used by AmigaDOS, MS-Windows, 
VMS (DEC MCS is practically equivalent to ISO 8859-1) and 
(practically all) UNIX implementations. MS-DOS normally 
uses a different character set and is not compatible with this 


character set. (It can, however, be translated to this format 
with various tools. See section 8.) 

ISO 8859-1 supports the following languages: Afrikaans, 
Basque, Catalan, Danish, Dutch, English, Faeroese, Finnish, 
French, Galician, German, Icelandic, Irish, Italian, Norwe¬ 
gian, Portuguese, Spanish, and Swedish. 

(It has been called to my attention that Albanian can be 
written with ISO 8859-1 also. However, from a standards 
point of view, ISO 8859-2 is the appropriate character set for 
Balkan countries.) 

ISO 8859-1 is just one part of the ISO 8859 standard, which 
specifies several character sets: 

8859-1 Europe, Latin America 
8859-2 Eastern Europe 

8859-3 SE Europe/miscellaneous (Esperanto, Maltese, etc.) 

8859-4 Scandinavia/Baltic (mostly covered by 8859-1 also) 

8859-5 Cyrillic 

8859-6 Arabic 

8859-7 Greek 

8859-8 Hebrew 

8859-9 Latin5, same as 8859-1 except for Turkish instead of 
Icelandic 

8859-10 Latin6, for Lappish/Nordic/Eskimo languages 

Unicode is advantageous because one character set suffices 
to encode all the world’s languages; however, very few pro¬ 
grams (and even fewer operating systems) support wide 
characters. Thus, only 8-bit wide character sets (such as the 
ISO 8859-X) can be used with these systems. Unfortunately, 
some programmers still insist on using the “spare” eighth 
bit for clever tricks, crippling these programs such that they 
can process only US-ASCII characters. 

Some people have complained about missing characters, 
e.g., French users about a missing “oe ” Note that “oe” is not 
a character, but a ligature (a combination of two characters 
for typographical purposes). Ligatures are not part of the 
ISO 8859-X standard. (Although “oe” used to be in the draft 
8859-1 standard, before it was unmasked as “mere” liga¬ 
ture.) 

3. Operating Systems and ISO 8859-1 

UNIX 

Most UNIX implementations use the ISO 8859-1 charac¬ 
ter set, or at least have an option to use it. Some systems 
may also support other encodings, e.g., Roman8 (HP- 
UX), DEC MCS (DEC Ultrix, see the discussion of DE on 
VMS), etc. 

NEXTSTEP 

NEXTSTEP uses a proprietary character set. 
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MS DOS 

IBM code page 819 is ISO 8859-1. Code Page 850 has the 
same characters as ISO 8859-1, but the characters are in dif¬ 
ferent locations (i.e., you can translate 1-to-l, but you do 
have to translate the characters). 

MS-Windows 

Microsoft Windows uses an ISO 8859-1 compatible 
character set (Code Page 1252), as delivered in the US, 
Europe (except Eastern Europe) and Latin America. In 
Windows 3.1, Microsoft has added additional characters 
in the 0x80-0x9F range. 

DEC VMS 

DEC VMS uses the DEC MCS character set, which is 
practically equivalent to ISO 8859-1 (it is a former ISO 
8859-1 draft standard). The only characters which differ 
between DEC MCS and ISO 8859-1 are the Icelandic 
characters (eth and thorn) at locations OxDO, OxFO, 
OxDE and OxFE. 

4. Table of ISO 8859-1 Characters 

This section gives an overview of the ISO 8859-1 character 
set. The ISO 8859-1 character set consists of the following 
four blocks: 


00 

19 

CONTROL CHARACTERS 

20 

7E 

BASIC LATIN 

80 

9F 

EXTENDED CONTROL CHARACTERS 

A0 

FF 

LATIN-1 SUPPLEMENT 


The control characters and basic Latin blocks are similar to 
those used in the US national variant of ISO 646 (US-ASCII), 
so they are not listed here. Nor is the second block of con¬ 
trol characters listed, for which functions have not yet been 
defined 


Table 1: The Latin-1 Supplement Characters.. 


Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1993(E) 

A0 

160 


NO-BREAK SPACE 

A1 

161 

■ 

INVERTED EXCLAMATION 
MARK 

A2 

162 


CENT SIGN 

A3 

163 

£ 

POUND SIGN 

A4 

164 

a 

CURRENCY SIGN 

A 5 

165 

¥ 

YEN SIGN 

A6 

166 


BROKEN BAR 


Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1993(E) 

A 7 

167 

§ 

SECTION SIGN 

A8 

168 

•• 

DIAERESIS 

A9 

169 

© 

COPYRIGHT SIGN 

AA 

170 

a 

FEMININE ORDINAL 

INDICATOR 

AB 

171 

« 

LEFT-POINTING DOUBLE 

ANGLE QUOTATION MARK 

AC 

172 

-i 

NOT SIGN 

AD 

173 

- 

SOF HYPHEN 

AE 

174 

® 

REGISTERED SIGN 

AF 

175 

- 

MACRON 

B0 

176 

• 

DEGREE SIGN 

B1 

177 

± 

PLUS-MINUS SIGN 

B2 

178 

2 

SUPERSCRIPT TWO 

B3 

179 

3 

SUPERSCRIPT THREE 

B4 

180 

' 

ACUTE ACCENT 

B5 

181 

V 

MICRO SIGN 

B6 

182 

i 

PILCROW SIGN 

B 7 

183 

• 

MIDDLE DOT 

B8 

184 

r 

CEDILLA 

B9 

185 

1 

SUPERSCRIPT ONE 

BA 

186 

O 

MASCULINE ORDINAL 
INDICATOR 

BB 

187 

» 

RIGHT-POINTING DOUBLE 
ANGLE QUOTATION MARK 

BC 

188 

1 

4 

VULGAR FRACTION ONE 
QUARTER 

BD 

189 

1 

2 

VULGAR FRACTION ONE 

HALF 

BE 

190 

9 

VULGAR FRACTION THREE 
QUARTERS 

BF 

191 

2 

INVERTED QUESTION MARK 

CO 

192 

H 

LATIN CAPITAL LETTER A WITH 
GRAVE ACCENT 
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Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1993(E) 

Cl 

193 

B 

LATIN CAPITAL LETTER A WITH 
ACUTE ACCENT 

C2 

194 


LATIN CAPITAL LETTER A WITH 
CIRCUMFLEX ACCENT 

C3 

195 

B 

LATIN CAPITAL LETTER A WITH 
TILDE 

C4 

196 

B 

LATIN CAPITAL LETTER A WITH 
DIAERESIS 

C5 

197 

A 

LATIN CAPITAL LETTER A WITH 
RING ABOVE 

C6 

198 

A. 

LATIN CAPITAL LIGATURE AE 

C7 

199 

c 

LATIN CAPITAL LETTER C WITH 
CEDILLA 

C8 

200 

E 

LATIN CAPITAL LETTER E WITH 
GRAVE ACCENT 

C9 

201 

E 

LATIN CAPITAL LETTER E WITH 
ACUTE ACCENT 

CA 

202 

A 

E 

LATIN CAPITAL LETTER E WITH 
CIRCUMFLEX ACCENT 

CB 

203 

E 

LATIN CAPITAL LETTER E WITH 
DIAERESIS 

CC 

204 

■ 

LATIN CAPITAL LETTER 1 WITH 
GRAVE ACCENT 

CD 

205 

1 

LATIN CAPITAL LETTER 1 WITH 
ACUTE ACCENT 

CE 

206 

fl 

LATIN CAPITAL LETTER 1 WITH 
CIRCUMFLEX ACCENT 

CF 

207 

■ 

LATIN CAPITAL LETTER 1 WITH 
DIAERESIS 

DO 

208 


LATIN CAPITAL LETTER ETH 

D1 

209 

N 

LATIN CAPITAL LETTER N WITH 
TILDE 

D2 

210 

6 

LATIN CAPITAL LETTER O 

WITH GRAVE ACCENT 

D3 

211 

6 

LATIN CAPITAL LETTER O 

WITH ACUTE ACCENT 

D4 

212 

6 

LATIN CAPITAL LETTER O 

WITH CIRCUMFLEX ACCENT 


Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1 993(E) 

D5 

213 

6 

LATIN CAPITAL LETTER O 

WITH TILDE 

D6 

214 

6 

LATIN CAPITAL LETTER O 

WITH DIAERESIS 

D7 

215 

m 

MULTIPLICATION SIGN 

D8 

216 

0 

LATIN CAPITAL LETTER O 

WITH STROKE 

D9 

217 

\ 

u 

LATIN CAPITAL LETTER U WITH 
GRAVE ACCENT 

DA 

218 

U 

LATIN CAPITAL LETTER U WITH 
ACUTE ACCENT 

DB 

219 

0 

LATIN CAPITAL LETTER U WITH 
CIRCUMFLEX ACCENT 

DC 

220 

0 

LATIN CAPITAL LETTER U WITH 
DIAERESIS 

DD 

221 

r 

Y 

LATIN CAPITAL LETTER Y WITH 
ACUTE ACCENT 

DE 

222 

P 

LATIN CAPITAL LETTER THORN 

DF 

223 

6 

LATIN SMALL LETTER SHARP S 

E0 

224 

a 

LATIN SMALL LETTER A WITH 
GRAVE ACCENT 

El 

225 

a 

LATIN SMALL LETTER A WITH 
ACUTE ACCENT 

E2 

226 

a 

LATIN SMALL LETTER A WITH 
CIRCUMFLEX ACCENT 

E3 

227 

a 

LATIN SMALL LETTER A WITH 
TILDE 

E4 

228 

a 

LATIN SMALL LETTER A WITH 
DIAERESIS 

E5 

229 

a 

LATIN SMALL LETTER A WITH 
RING ABOVE 

E6 

230 

ae 

LATIN SMALL LIGATURE AE 

E7 

231 

C 

LATIN SMALL LETTER C WITH 
CEDILLA 

E8 

232 

e 

LATIN SMALL LETTER E WITH 
GRAVE ACCENT 

E9 

233 

e 

LATIN SMALL LETTER E WITH 
ACUTE ACCENT 
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Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1 993(E) 

EA 

234 

e 

LATIN SMALL LETTER E WITH 
CIRCUMFLEX ACCENT 

EB 

235 

e 

LATIN SMALL LETTER E WITH 
DIAERESIS 

EC 

236 

■ 

LATIN SMALL LETTER 1 WITH 
GRAVE ACCENT 

ED 

237 

\ 

LATIN SMALL LETTER 1 WITH 
ACUTE ACCENT 

EE 

238 

T 

LATIN SMALL LETTER 1 WITH 
CIRCUMFLEX ACCENT 

EF 

239 

T 

LATIN SMALL LETTER 1 WITH 
DIAERESIS 

F0 

240 

ar 

LATIN SMALL LETTER ETH 

FI 

241 

n 

LATIN SMALL LETTER N WITH 
TILDE 

F2 

242 

6 

LATIN SMALL LETTER O WITH 
GRAVE ACCENT 

F3 

243 

6 

LATIN SMALL LETTER O WITH 
ACUTE ACCENT 

F4 

244 

6 

LATIN SMALL LETTER O WITH 
CIRCUMFLEX ACCENT 

F 5 

245 

o 

LATIN SMALL LETTER O WITH 
TILDE 

F6 

246 

6 

LATIN SMALL LETTER O WITH 
DIAERESIS 

F7 

247 

-f 

DIVISION SIGN 

F8 

248 

0 

LATIN SMALL LETTER O WITH 
OBLIQUE BAR 

F9 

249 

u 

LATIN SMALL LETTER U WITH 
GRAVE ACCENT 

FA 

250 

u 

LATIN SMALL LETTER U WITH 
ACUTE ACCENT 

FB 

251 

0 

LATIN SMALL LETTER U WITH 
CIRCUMFLEX ACCENT 

FC 

252 

u 

LATIN SMALL LETTER U WITH 
DIAERESIS 


Hex 

Dec 

Car 

Description ISO/IEC 10646- 
1:1993(E) 

FD 

253 

y 

LATIN SMALL LETTER Y WITH 
ACUTE ACCENT 

FE 

254 

P 

LATIN SMALL LETTER THORN 

FF 

255 

■ 

LATIN SMALL LETTER Y WITH 
DIAERESIS 


Note: ISO 10646 calls /E a “ligature,” but this is supposedly 
a letter in Scandinavian languages. Thus, it is not in the 
same, merely typographic, “ligature” class as “oe” (which 
was not included in the ISO 8859-1 standard). 

5. Configuring your terminal to 
handle 8-bit characters 

Terminal drivers normally do not pass 8-bit characters. To 
enable proper handling of ISO characters, add the following 
lines to your .cshrc: 

tty -s 

if ($status == 0) stty cs8 -istrip -parent 

If you don’t use csh, add equivalent code to your shell’s 
start up file. 

Note that it is necessary to check whether your standard I/O 
streams are connected to a terminal. Only then should you 
reconfigure the terminal driver. Note that tty checks 
stdin, but stty changes stdout. This is OK in normal 
code, but if the . cshrc is executed in a pipe, you may get 
spurious warnings If you use the Bourne Shell or 
descendants (sh, ksh, bash, zsh), use this code in your 
startup (e.g., .profile) file: 

tty -s 

if [ $? = 0 ]; then 

stty cs8 -istrip -parenb >&0 
fi 

In the /bin/sh version, we redirect stdout to stdin, so 
both tty and stty operate on stdin. This resolves the 
problem discussed in the /bin/csh script version. A possi¬ 
ble workaround is to use the following code in . cshrc, 
which spawns a Bourne shell (/bin/sh) to handle the redi¬ 
rection: 

tty - s 

if ($status == 0) sh -c "stty cs8 -istrip - 
parenb >s0" 
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6. Getting the locale setting right 

For the ctype macros (and by extension, applications you 
are running on your system) to correctly identify accented 
characters, you may have to set the ctype locale to an ISO 
8859-1 conforming configuration. On SunOS, this may be 
done by placing 

setenv LANG C 

setenv LC_CTYPE iso_8859_l 

in your . login script (if you use the csh). An equivalent 
statement will adjust the ctype locale for non-csh users. 

The process is the same for other operating systems, e.g., on 
HP-UX use “setenv LANG german . iso88591;” on IRIX 
5.2 use “setenv LANG de;” on Ultrix 4.3 use “setenv 
lang ger_de . 8859;” and on OSF/1 use “setenv LANG 
de_DE .88591.” The examples given here are for German. 
Other languages work too, depending on your operating sys¬ 
tem. Check out “man setlocale” on your system for more 
information. 

Note on HP-UX systems: as of 10.0, you can use either ger- 
man.iso88591 or de_DE.iso88591 (a name more in line with 
other vendors and developing standards for locale names). 
For a complete listing of locale names, see the text file 
/usr/lib/nl s/con f ig. Or, on HP-UX 10.0, execute locale 
-a . This command will list all locales currently installed on 
your system. 

7. Selecting the right font under X-ll 
(for xterm and other applications) 

To actually display accented characters, you need to select a 
font which does contains bit maps for ISO 8859-1 characters 
in the correct character positions. The names of these fonts 
normally have the suffix “iso8859-l.” Use the command: 

# xlsfonts 

to list the fonts available on your system. You can preview a 
particular font with the command: 

# xfd -fn <fontname> 

Add the appropriate font selection to your ~/.Xdefaults file, 
e.g.: 

XTerm*Font: -adobe-courier-medium-r-normal--18-180- 
75-75-m-110-iso8859-l 

Mosaic*XmLabel*fontList: -*-helvetica-bold-r-normal 
_*_14-*_*_*-*-*_i S0 8859-l 

Note: The XI1R5 distribution has some fonts which are labeled as 
ISO fonts, but which contain only the US-ASCII characters. 


8. Translating between different 
international character sets 

While ISO 8859-1 is an international standard, not every¬ 
body uses this encoding. Many computers use their own, 
vendor-specific character sets (most notably Microsoft for 
MS-DOS). If you want to edit or view files written in differ¬ 
ent encoding, you will have to translate them to an ISO 
8859-1 based representation. 

There are several PD/free character set translators available 
on the Internet, the most notable being “recode.” recode 
is available from URL ftp://prep.ai.mit.edu/u2Iemacs. 
recode is covered by FSF copyright and is freely redistri¬ 
butable. 

The general format of the recode program call is one of: 

recode [OPTION]... [BEFORE]:[AFTER] [FILE] 

Each file will be read assuming it is coded with charset 
before; it will be recoded over itself so to use the charset 
after. If there is no such file, the program rather acts as 
a filter and recodes standard input to standard output. 

Some recodings are not reversible, so after you have con¬ 
verted the file (recode overwrites the original file with the 
new version!), you may never be able to reconstruct the 
original file. A safer way of changing the encoding of a file 
is to use the filter mechanism of recode and invoke it as 
follows: 

recode [OPTION]... [BEFORE]:[AFTER] 

<[OLDFILE]<[NEWFILE] 

Using recode, you can translate MS-DOS data to ISO 8859- 
1 using the following command: 

recode ibm-pc:latin-1 <[DOS-FlLE] >[UNIX-FILE] 

Under SunOS, the dos2unix and unix2dos programs (dis¬ 
tributed with SunOS) will translate between MS-DOS and 
ISO 8859-1 formats. 

It is somewhat more difficult to convert German, “Duden”- 
conformant Ersatzdarstellung (a = ae, B = sz, etc.) into the 
ISO 8859-1 character set. The German dictionary available 
as URL 

ftp:llftp.vlsivie.tuwien.ac.at/pub/8bitfdicts/deutschJangz 

also contains a UNIX shell script which can handle all con¬ 
versions except ones involving B (German scharfes-s); as 
for “ss,” this change is more complicated. 

A more sophisticated program to translate Duden Ersatz¬ 
darstellung to ISO 8859-1 is Gustaf Neumann’s diac pro¬ 
gram (version 1.3 or later) which can translate all ASCII 
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sequences to their respective ISO 8859-1 character set rep¬ 
resentation. “diac” is available in URL 

ftp:Hftp.vlsivie.tuwien.ac.at/pub/8bit/diac. 

Translating ISO 8859-1 to ASCII can be performed with a 
little sed script according to your needs. But be aware that: 

• No one-to-one mapping between Latin 1 and ASCII 
strings is possible. 

• Text layout may be destroyed by multi-character substitu¬ 
tions, especially in tables. 

• Different replacements may be in use for different lan¬ 
guages, so no single standard replacement table will make 
everyone happy. 

• Truncation or line wrapping might be necessary to fit tex¬ 
tual data into fields of fixed width. 

• Reversing this translation may be difficult or impossible. 

• You may be introducing ambiguities into your data. 

9. Printing accented characters 

9.1 PostScript printers 

If you want to print accented characters on a Postscript 
printer, you may need a PS filter which can handle ISO char¬ 
acters. 

Our Postscript filter of choice is a2ps, the more recent ver¬ 
sions of which can handle ISO 8859-1 characters with the -8 
option. a2ps V4.3 is available as URL 
ftp.ifimag. imag.fr/archive!postscript! a2ps. V4.3.tar. gz. 

If you use the pps Postscript filter, use the “pps -ISO” 
option for pps to handle ISO 8859-1 characters properly. 

9.2 Other (non~PS) printers 

If you want to print to non-PS printers, your success rate 
depends on the encoding the printer uses. Several alterna¬ 
tives are possible: 

• Your printer accepts ISO 8859-1: You’re lucky. No con¬ 
version is needed, just send your files to the printer. 

• Your printer supports a PC-compatible font: You can use 
the recode tool to translate from ISO 8859-1 to this 
encoding. (If you are using a SunOS based computer, you 
can also use the unix2dos utility which is part of the stan¬ 
dard distribution.) Just add the appropriate invocation as a 
built-in filter to your printer driver. 


• Your printer uses a national ISO 646 variant (7-bit ASCII 
with some special characters replaced by national charac¬ 
ters): You will have to use a translation tool; this tool 
would then be installed in the printer driver and translate 
character conventions before sending a file to the printer. 
The recode program supports many national ISO 646 
norms. (If you add this, please submit it to the maintainers 
of recode, so that it can benefit everybody.) Unfortu¬ 
nately, you will not be able to display all characters with 
the built-in characters set. Most printers have user-defin¬ 
able bit-map characters, which you can use to print all ISO 
characters. You just have to generate a pix-map for any 
particular character and send this bitmap to the printer. The 
syntax for these characters varies, but a few conventions 
have gained universal acceptance (e.g., many printers can 
process Epson-compatible escape sequences). 

• Your printer supports a strange format: If your printer sup¬ 
ports some other strange format (e.g., HP Roman8, DEC 
MCS, Atari, NeXTStep, EBCDIC or what have you), you 
have to add a filter which will translate ISO 8859-1 to this 
encoding before sending your data to the printer, recode 
supports many of these character sets already. If you have 
to write your own conversion tool, consider this as a good 
starting base. (If you add support for any new character 
sets, please submit your code changes to the maintainers of 
recode). 

If your printer supports DEC MCS, this is nearly equivalent 
to ISO 8859-1 (actually, it is a former ISO 8859-1 draft 
standard. The only characters which are missing are the 
Icelandic characters (eth and thorn) at locations OxDO, 
OxFO, OxDE and OxFE) - the difference is only a few char¬ 
acters. You could probably get by with just sending ISO 
8859-1 to the printer. 

• Your printer supports ASCII only: You have several 
options: 

If your printer supports user-defined characters, you can 
print all ISO characters not supported by ASCII by send¬ 
ing the appropriate bitmaps. You will need a filter to con¬ 
vert ISO 8859-1 characters to the appropriate bitmaps. (A 
good starting point would be recode.) 

Add a filter to the printer driver which will strip the 
accent characters and just print the unaccented charac¬ 
ters. (This character set is supported by recode under 
the name “flat” ASCII.) 

Add a filter which will generate escape sequences (such 
as "<BACKSPACE> a for Umlaut-a (a), etc.) to be 
printed, recode supports this encoding under the name 
“ascii-bs.” 

Note: For more information on character translation and the 

“recode” tool, see section 8. 
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10. Operating System Considerations 

10.1 File names with ISO characters 

If your OS is 8-bit clean, you can use ISO characters in file 
names. (This is possible under SunOS and several other 
operating systems.) 

10.2 Command names with ISO 8859-1 
Characters 

If your OS supports file names with ISO characters, and your 
shell is 8-bit clean, you can use command names containing 
ISO characters. If your shell does not handle ISO characters 
correctly, use one of the many PD shells which do (e.g., 
tcsh, an extended csh). These are available from a multi¬ 
tude of ftp sites around the world. 

UNIX Tip: I Can Never 
Remember Those Pesky 
Options 

by Greg Rose 

<ggr@sydney. sterling. com> 

There are some wonderful tools under UNIX that I always 
seem to use for some purpose other than that which was 
intended. (Doug Mcllroy said that this was a proof of the 
correctness of the tool approach.) One of them is that if I 
can’t quite remember a person’s email address, it is much 
easier to telnet to the mail server and ask it than to send trial 
messages and wait for them to bounce. But you have to 
know the real name of the machine ... 

Now “nslookup” is a wonderful tool, but you have to get 
into it, remember to say “set type=mx” to get mail 
exchange records out, and (depending on your configuration) 
remember to end the mail domain name with a which is 
very counterintuitive, so what ends up happening is: 

$ nslookup 

Default Server: paganini.sydney.sterling.com 
Address: 199.0.91.253 

> set type=mx 

> sterling.com 

Server: paganini.Sydney.sterling.com 
Address: 199.0.91.253 

sterling.com.Sydney.sterling.com 
preference = 10/ 

mail exchanger = sibelius.sydney.sterling.com 
[Damn. . . did it again. . .] 


sterling.com. 

Server: paganini.Sydney.sterling.com 
Address: 199.0.91.253 

sterling.com preference = 10, 
mail exchanger = ns.sterling.com 

> 

Well, after doing this about 50 times in the last two weeks 
(no, not all for the same machine), I concluded that there 
would probably be CONFIGURATION OPTIONS on the 
nslookup command. (I can be a bit slow sometimes.) 

So, after looking up the manual page, I found that there are 
such options, but that the chance of me remembering them 
was negligible. So, I embedded them into a shell script (or 
alias if you prefer, but I find one-line shell scripts easier to 
share around, and who cares about the efficiency?). 

Here, then, is “mxlookup”: 

#!/bin/ksh 

nslookup '-set type=mx' '-set nosearch 1 $1 

And an example use: 

$ mxlookup qantel.com.au 

Server: paganini.Sydney.sterling.com 

Address: 199.0.91.253 

qantel.com.au preference = 0, 
mail exchanger = gatekeeper.qantel.com.au 
gatekeeper.qantel.com.au 
inet address = 203.5.27.252 

The point of this tip is not about nslookup, particularly, but 
about the idea of embedding weird options into little shell 
scripts, rather than having to remember them. 

UNIX Tip: What was that weird 
prompt you use? 

I like to use prompts like: 

: /tmp; 

Lots of people embed useful (or useless) information in their 
prompt strings. In my case it is the directory I’m in (or subdi¬ 
rectory of my home directory), and the machine name if I’m 
not on the normal one. But what is the and for? Why 
not use “$” or “%”? 

Well, the is a do-nothing command to most shells. And the 
is the command terminator. Everything in between is argu¬ 
ments to the which are happily ignored when executed. 
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Executed? EXECUTED?? Am I really trying to tell you that 
I execute my prompts? Yep. 

What this buys me is very simple. Under X-Windows, in an 
xterm, I can triple click on a command line and have it 
select the entire line, then paste it with another click and 
have it executed. The prompt doesn’t get in the way! It gets 
executed too, but who is to know or care? This is a major 
win for an uncoordinated person who uses small fonts. In 
case you are wondering, my secondary prompt is a few 
spaces and a Bell (control-G) character, which is hard to 
miss while typing, but can be cut-and-pasted just as simply. 

UNIX Tip: What was that about 
telnet and SMTP? 

Did you know that you can give telnet any old port number 
to talk to? This is most useful, in my experience, to verify 
people’s correct mail addresses, or to find out who is on 
mail exploders. Here is an example: 

: /tmp; mxlookup dialix.oz.au 
[. ■ ■] 

dialix.oz.au preference = 900, 
mail exchanger = perth.DIALIX.OZ.AU 

: /tmp; telnet perth.DIALIX.OZ.AU smtp 
Trying... 

Connected to perth.DIALIX.OZ.AU. 

Escape character is . 

220-perth.DIALix.oz.au Sendmail 8.6.11/ 

8.6.11/DIALixready at Fri, 24 
Mar 1995 15:45:44 +0800 

220 ESMTP spoken here 
vrfy janet 

250 Janet Jackson <janet@perth.DIALix.oz.au> 
quit 

221 perth.DIALix.oz.au closing connection 
Connection closed. 

Note the extra argument to the telnet command. It looks up 
“smtp” in the /etc/services file or equivalent, and since 
it isn’t the other end of telnet, it ignores protocols and just 
starts talking. Now I can type at the Sendmail at the other 
end (and note that they are running a good Sendmail, Eric 
will be pleased). 

The “vrfy” command asks it to tell me what will happen to 
mail addressed to “janet.” Another useful command is 
“expn” to expand mailing list addresses (depending how 
they are implemented). I think “quit” is pretty self explan¬ 
atory. Marshall Rose’s (no relation) book The Internet Mes¬ 
sage is a great introduction to this stuff. This is also how 
you forge mail, but I ask you not to do that. 

UNIX Tip: How do I generate a lot of lines? 

Sometimes you need to generate a lot of lines, but a particu¬ 
lar number of them. Other times you might need a list of 


unique somethings. I wrote a script one day when both of 
these situations happened to me within hours of each other. 
The thing that both of these have in common is that you 
don’t particularly care what the list has in it. 

Sometimes you actually want a list of numbers. The APL 
“iota” function, or equivalent. Once Perl came along, this 
became particularly easy, but the original version of this 
script was much less functional, and predated Perl. 

The first use I had was to simply execute the same com¬ 
mand ten times. I got used to typing: 

: ; for i inxxxxxxxxxx; 
do <command>; done 

... except of course I always either miscounted or mistyped 
the line. Now I say: 

: ; for i in "count 10"; do <command>; done 

... and I’m less likely to make a mistake. 

The other thing I needed it for that day was creating a bunch 
of special files in the /dev directory. I know I’m showing 
my age here. But I could type: 

# for i in "count 0 63"; do /etc/mknod 
/dev/special$i c 7 $i; done 

and be reasonably sure I did it right. I once wiped out the 
contents of a disk because of a typo in the middle of a 
sequence of individually typed commands to make the 
devices one at a time. 

Anyway, here is the script if you want it. It is much more 
complicated than it needs to be for the examples I’ve given, 
but it has nice defaults. 

#!/usr/bin/perl 
generate a list of numbers 

if { @ARGV > 3 || grepC/C^-O-Q]/, <§ARGV) ) { 
die "usage: $0 [[low] high [incre¬ 
ment] ]\n" 

} 

if ( @ARGV == 0) { 

$low = 1; 

$high = 10; 

$incr = 1; 

} elsif (OARGV == 1) { 

$low - 1; 

$high = $ARGV [0]; 

$incr = 1; 

} elsif ( @ARGV == 2) [ 

$low = $ARGV[0]; 

$high = $ARGV[ 1 ]; 

$incr = 1; 

} elsif { @ARGV == 3) [ 
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$low = $ARGV[0]; 
$high = $ARGV[1]; 
$incr = $ARGV[2]; 
} else {die;} 

# generate 


if 

($incr > 0 

) 1 





for ($i = 

$low; $i <= 

$high; 

$i +- 

$incr)[ 


print 

1 

$i/ "\n"; 




1 

if 

($incr < 0 

) ( 





for ($i = 

$low; $i >= 

$high; 

$i += 

$incr){ 


print 

$i/ "\n"; 





} 

} 


Possible Future User 
Interfaces 

by Scott Hazen Mueller 
< scott@zorch.sf- bay. org> 

In a recent article I speculated briefly about the effect giga- 
technologies would have on user interfaces. Since I use com¬ 
puters all of my working hours, and many of my non-work¬ 
ing ones, I have a vested interest in how I use them. Like 
many of us, I have been keyboarding for many years. I 
skipped punch cards, but I backed my first programs up onto 
paper tape, and I remember what a real teletype sounds like. 

Most modem interfaces are simply elaborations on the origi¬ 
nal keyboard interface, and I don’t think it is going to go 
away soon. The keyboard is still the most efficient way to 
enter bulk text, and memos and letters and so on are still very 
important to the way the world works. Furthermore, writing 
is a very effective compression method, much more so than 
anything that has been done with audio so far. Some day I’m 
sure space really won’t matter at all, but that time is still 
down the road a ways. 

Some work has been done in the area of pen-based input, but 
that is a niche market and is likely to stay that way. Hand¬ 
writing is just too inefficient for any volume of work; can 
you imagine writing a paper (or this article) by hand? I’m not 
disputing that great works were written by hand, but once the 
keyboard interface was invented, the writing world moved to 
it en masse. The advantages to pen-based input are twofold: 
one, the pen is more compact than the keyboard; and two, the 
pen can double as a pointing device. 

Researchers have been working on other input methods as 
long as there have been computers. Speech input has been 
around for a few years, but the current implementations have 
many drawbacks. I think that speech input will have a defi¬ 


nite place in the user interface of the future. However, 
speech input also has drawbacks, such as the (fictional, so 
far) story of the disgruntled employee who ran around an 
office full of speech-enabled computers yelling “File! 

Close! Yes!” 

Another input method that holds promise is direct com¬ 
puter-brain interfacing. A certain amount of work has been 
done in this area, starting with work years ago in biofeed¬ 
back techniques and continuing through recent work in 
more sophisticated means. However, this still has a long 
way to go until we reach the point depicted in science fic¬ 
tion stories of being able to meld with the computer and 
achieve superhuman brilliance. 

I do think that an area that has considerable room for 
improvement, and that should be fairly easy to improve, is 
how we point at places on the display. Most commonly we 
use pointing devices, such as mice or track balls; sometimes 
we use touch-screens or light pens. Except for touch¬ 
screens, we use some extra device that is tied to the com¬ 
puter in some way (and touch-screens have their own set of 
problems, such as getting fingerprints on the screen). 

I’d really like to have the computer just know what I’m 
looking at, and do away with the pointing device paradigm 
altogether. That’s a really tough job computationally, and 
would have its own set of problems, like distractions from 
co-workers. It would certainly be convenient, if it could be 
done while still giving fine control over positioning. If some 
sort of head-tracking technology becomes common, I do 
predict a whole new regime of Repetitive Stress Injuries, 
and a booming business in neck braces. 

Of course, there are some things that get more complicated 
if you don’t have mouse buttons, like selecting a region. 
This may indicate we’ll have to keep mechanical pointers 
for precision work, but perhaps not. If the applications were 
more object-oriented, they could understand the structure of 
the text they were working with - documents, code, and so 
on - whereupon motion and selection operations could be 
phrased in terms of visible text elements (words, sentences, 
lines) and the applications could be expected to deal with 
them correctly. Furthermore, by combining body tracking, 
context sensitivity and voice input, all of this action could 
be essentially hands free, allowing even faster keyboard 
input. Imagine eyeing a paragraph of text and saying, 
“Computer! Select paragraph!” 

On the output side, the current technological trends point 
only to incremental improvements in how information is 
displayed. For example, screens are getting bigger, cheaper 
and flatter, but they’re still basically screens, and they’re 
still mostly displaying text, I don’t see significant change in 
this area without new paradigms. 
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All of these things are part of the human interface with the 
system itself. What sort of new user interfaces will applica¬ 
tions show in the future? 

I have seen part of this future, and it’s called (now) “drag 
and drop.” I think the current implementations are primitive 
compared to what they can be. It shares some philosophy 
with object-oriented design, because the entities that are 
dropped are in some sense “objects,” with attributes and 
information. Current interfaces exhibit some object-like 
behavior, for example, selecting a file icon could start an 
associated application. More advanced interfaces may hide 
the file paradigm but still make the associated information 
available both as a whole (your entire schedule could be 
represented by an image of a calendar) and, in parts (where 
you view your calendar and select items from it). Still more 
advanced interfaces and applications could treat your indi¬ 
vidual calendar as part of a global amalgam of schedules, 
and allow access to any subset that you have permission to 
access. 

Not only are accesses within the same type easier, more 
powerful, and more global, but the information can be 
transferred into an entirely different application and inter¬ 
preted in a useful manner. For example, consider taking an 
appointment object and dropping it onto a representation of 
a phone, and having that generate an automatic phoned 
reminder of the appointment at the proper time. This is not 
even that far-fetched, but the total integration of applica¬ 
tions is going to require considerable system resources, and 
may not be practical until the technology catches up. 

Of course, the most talked-about user interface now is 
Mosaic and its family of Web browsers. As they grow more 
popular, more and more functionality is coming to live 
within the browser framework. They already read and post 
to Usenet, and send (but not usually read) e-mail. Eventu¬ 
ally, rather like Emacs, I imagine the browsers will become 
a complete user environment. If they are converged with 
new hardware interface technologies and object-oriented 
application interfaces, they will become a comfortable com¬ 
puting environment for millions of people. They will be 
used as tools to navigate a combined information space, 
where all of the system’s local resources are on a par with 
resources on the Internet. 

While current browsers don’t provide object-like interfaces, 
the Web itself is not hostile to object data types. The under¬ 
lying structure of the HyperText Transfer Protocol (HTTP) 
is really quite flexible and extensible. The HotJava browser 
from Sun is an example of using the Web in a more object- 
oriented fashion. If the capability for exchanging and run¬ 
ning applets is continues to be extended, then I see a clear 
growth path from current browser technology to an object- 
oriented front-end for all sorts of applications. 


Both object-oriented interfaces and graphical information 
browsers put heavy demands on the input side of the user 
interface. They will help to drive the creation of new tech¬ 
nologies for object and link selection. Even the Web has fill- 
in forms, however, and I’m sure that for a long time we’ll 
still be keyboarding away. 


Musings 

by Rik Farrow 
< rik@sp irit. com > 

Although you won’t be reading this for a while, the big news 
lately has been about SATAN, Dan Farmer and Wietse Ven- 
ema’s new security tool. With the biggest media buildup 
since the Michaelangelo Virus spread (remember that one? 
a real dud . ..), SATAN had been “on the streets” officially 
only a week before the authors had to put out version 1.1 
because version 1.0 may permit an attacker to execute com¬ 
mands while an administrator is running SATAN ! 

Oh well, I was going to comment that the best thing about 
SATAN was its innovative use of a Web browser as the user 
interface. Perhaps I should start instead by listing the good 
things that SATAN will do for you: 

• Check for world-exported NFS file systems, systems which 
will accept mount requests made from non-privileged 
ports (greater than 1023), and portmappers which will 
proxy remote requests (so they appear to be coming from 
the local host). 

• Attempt to collect the password file, complete with 
encrypted passwords suitable for cracking, from NIS (Net¬ 
work Information System) servers. 

• Try some old sendmail problems, such as sending mail to 
an arbitrary file or a pipe. Or perhaps not so old, as CERT 
released a vendor bulletin from HP about, you guessed it, 
being able to execute arbitrary commands from HP’s ver¬ 
sion of sendmail . Get your patches today if you haven’t 
already. FTP to info.cert.org , and get the HP vendor bulle¬ 
tin in the fpubfvendors directory. [Ed. Note: SATAN checks 
for some of these implicitly rather than explicitly .] 

• Check for unrestricted access to rexd\. 

• Attempt to connect to X servers (check access control on X 
servers). 

• Collect arbitrary files using tf tp. 
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• Check for equivalenced hosts by using rsh (same trick 
used by the Internet Worm in 1988, and Kevin Mitnick in 
1994). 

• Attempt to write a file in the root directory of any anony¬ 
mous FTP servers found. 

Version 1.1 will include a new check: it will look for version 
1.0 SATAN, which includes the Web browser vulnerability. I 
believe this is the first security tool which checks for a secu¬ 
rity vulnerability introduced by a previous version of itself. 

As Farmer and Venema have said, none of these vulnerabil¬ 
ities is new (except the one introduced by SATAN itself). 
Other tools, like Chris Klaus’ ISS (Internet Security Scan¬ 
ner, found at aqigatech.edu.lpublsecurityliss.iss.shar), 
probe for similar vulnerabilities. The real difference is in the 
presentation. 

The versions of ISS I have used did a terrible job of present¬ 
ing results. You had to read and understand the C code to 
make use of the output of ISS (Chris may have fixed this by 
now). But SATAN is different. It puts a pleasant face on a 
useful tool by using a Web browser as its interface. 
Although this wound up introducing a new hole, I’d like to 
focus on this aspect for a moment. 

The Web as the Client-Server Protocol 

Instead of writing a user interface for SATAN in Motif (still 
not portable, especially to old Suns), or Tcl/Tk, Farmer and 
Venema chose to use a Web browser as the user interface. 
Web servers, of course, can send forms which may be filled 
out and returned by the user of a Web browser. By making 
use of this behavior, Farmer and Venema are using what 
may become the client-server interface of the near future. 

Think about it. It seems like everybody and his or her dog 
has (or wants to get) a Web browser so they too can explore 
the Internet. The Web browser interprets text files with 
embedded HTML (HyperText Markup Language) com¬ 
mands to work its magic. Besides creating anchors (refer¬ 
ences to other resources via URLs), HTML can be used to 
add graphical elements such as lines or bitmaps or sound 
files. HTML can also be used to create interactive elements, 
such as fields for strings, pushbuttons, even scrolling text 
entry regions. 

And you can generate text files containing HTML directives 
with shell scripts, programs, PERL, TCL, etc.. SATAN, at 
least partially, emulates a Web server to interact with the 
browser, coaxing the browser to collect the user’s input and 
to display the output of SATAN’s network scans. HTML is 
the platform-independent input-output format for SATAN 
today, and maybe many other applications tomorrow. 


Oracle and Sybase have already created CGI (Common 
Gateway Interface, the mechanism for passing collected 
input from a Web server to an application) interfaces for 
their database products. In other words, you can write cli¬ 
ent-server applications using a text editor to create the 
forms, a Web browser for the client, and a Sybase or Oracle 
database (sitting behind the Web server) as the back end. No 
more Power Builder, Visual Basic, etc., necessary. 

How far HTML will get as a client-server interface is any¬ 
body’s guess, but it sure got me thinking about it. Perhaps it 
was just the thought of having to sit down and learn about 
Windows, so I could learn about Visual Basic, so I could 
create client interfaces which can crash unpredictably. Well, 
you get the idea. I’d rather stick to something I know and 
trust - like using vi to create the HTML files to be used as 
the interface. 

Power Broker 

I did get a chance to use O’Reilly and Associates new book, 
Managing Internet Services, written by a collection of 
O’Reilly authors. Over 400 pages, I lugged it around with 
me and found it helpful in filling in some gaps in my knowl¬ 
edge of Internet servers, especially gopher and Web serv¬ 
ers. While the four or five chapters on the Web were quite 
good, you want more if your job title has become “Webmas¬ 
ter.” All-in-all, a useful book for the harried system admin¬ 
istrator. 

I also discovered another slim package, buried under the 
piles of mail which seem to accumulate on my desk. Dan 
Freedman, of Freedman Sharp and Associates, had sent me 
a copy of PowerBroker to review. PowerBroker provides a 
method for sharing root access without sharing the root 
password. If this is all it did, of course, you’d be better off 
using sudo, a free program which permits users to execute 
commands as root under the control of a configuration file. 

PowerBroker works with networks of Sun, HP, IBM, DEC, 
SGI, or Motorola (remember the 88K standard?) systems. 
Like sudo, you configure it by editing a configuration file. 
Unlike sudo, PowerBroker extends your control of root 
access across the network. It also keeps track of any process 
started, so it can terminate a program attached to an unat¬ 
tended window, or capture all input-output of selected pro¬ 
grams so you have a complete record of what went on 
(along with time stamps). 

Logging is performed by writing to a central log machine, 
presumably one to which the PowerBroker’ed root users 
have no access. The marketing literature calls this an “indel¬ 
ible record,” something which I don’t consider true (only 
printers and WORM drives make nearly indelible records). 
Still, PowerBroker provides tools for replaying logs, or 
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even monitoring activity while in progress, as long as that 
activity was started via PowerBroker. 

PowerBroker includes session encryption as an option, 
something which should not be an option for networked ses¬ 
sions, in my opinion. Installation requires copying files to 
each machine and running pbinstall or sharing a file sys¬ 
tem containing the master copies which has been NFS- 
exported with root access privileges. 

Prices for PowerBroker vary, starting around $9000 for 
thirty systems, to $93,000 for 1000 systems (expect to pay 
15% annually for support). You can find out more about 
PowerBroker by sending e-mail to info@fsa.com . The docu¬ 
mentation is just over 90 pages, and includes an index. 

Should you buy it? How would I know? I just thought it 
looked useful and interesting. I think its major disadvantage 
is the configuration interface (you must learn PowerBro- 
ker’s syntax), which, while not alien to UNIX users and 
somewhat C-like, will limit its use to the competent sysad¬ 
mins. Which is perhaps as it should be. 


Top Ten Anagrams 
for Information Super¬ 
highway 

Found on the net by Kevin M. Savetz 
<savetz@northcoast.com> 

10. Enormous, hairy pig with fan 
9. Hey, ignoramus - win profit? Ha! 

8. Oh-oh, wiring snafu: empty air 
7. When forming, utopia’s hairy 
6. A rough whimper of insanity 
5. Oh, wormy infuriating phase 
4. Inspire humanity, who go far 
3. Waiting for any promise, huh? 

2. Hi-ho! Yowl I’m surfing Arpanet! And the number 
one anagram for Information Superhighway: 

1. New utopia? Horrifying sham. 

Runners-up: 

Fury, morphia, a wise nothing 
Hey, what of inspiring amour? 

How pithy - a finer ignoramus 
I swamp, horrify huge nation 
I whisper nothing of my aura 
Newt has a horrifying opium 
This warning of my euphoria 
Whining, amorphous - yet fair 
Why shun origin of a primate? 

Wishing for a utopian rhyme 
I’m on a huge wispy rhino fart 
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The following reports are 
published in this column: 

•PASC 

•POSIX.O 

• POSIX.1 
•POSlX.lg 
•POSIX.21 

• POSIX.4 

•POSIX System Administration 
•POSIX Conformance Testing 
•Programming for the Real World 

Our Standards Report Editor, 

Nick Stoughton, welcomes dia¬ 
logue between this column and 
you, the readers. Please send any 
comments you might have to 
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An Update on 
Standards Relevant to 
USENIX Members 

by Nick Stoughton 

USENIX Standards Report Editor 

< nick@hoskyns. co. uk> 

A Report From The Chair 

by Lowell Johnson, 

Chair IEEE Portable Applications Standards Committee 

PASC, the IEEE Portable Applications Standards Committee, has been undergo¬ 
ing a lot of changes over the last year or two. The most notable have been the 
decline in participation, the completion of 27 standards (undoubtedly part of the 
reason for the declining participation), and the smaller, more focused projects 
which are now being started. There are more changes coming in the future, but I 
will defer reporting on them for the present. 

The primary topic of this report, and probably the most visible change, is the new 
organization structure adopted by the SEC (the Sponsor Executive Committee of 
PASC) at its last meeting on April 27 in Irvine, CA. A reorganization of some sort 
has been in the works since the October, 1993 meeting in Bethesda, MD. How¬ 
ever, I think a little organizational history is appropriate before we get into the 
new structure itself. 

When PASC (then TCOS - the Technical Committee on Open Systems) was 
younger, there was basically a new working group created (with a chair on the 
SEC) for each new project approved. Once we had over six or seven groups we 
started assigning some new projects to existing groups and some to new groups. 
If a new project was given to an existing group, it was usually because that was 
where most of the people who would be working on the project were located. 

As we grew larger, a significant number of projects were eventually going to 
either modify or amend existing projects or standards; the first and most complex 
case being POSIX.1. Special committees had to be created to coordinate the activ¬ 
ities of the various working groups. ISO had defined three projects where much 
(but certainly not all) of the PASC standards would reside when they achieved IS 
status. They are: 

• 9945-1 System Application Program Interfaces 

• 9945-2 Shell and Utilities 

• 9945-3 System Administration 

IEEE then gradually began renumbering the PASC projects to better align them 
with their eventual ISO homes: for example, all projects that would end up in ISO 
9945-1 were renumbered to the form 1003.1 x where x was just the next available 
letter in the alphabet. A complete list of all project numbers (old and new) is 
appended at the end of this paper. 

We then had a very large SEC, with working groups that were not organized in 
the most logical fashion. As the PASC participation declined and many projects 
became smaller, the SEC became disproportionately large in relation to the total 
PASC membership. At its largest, the SEC had about 38 voting members, plus 
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several non-voting liaisons, and other senior people who 
attended without an official vote. Generally the SEC meet¬ 
ings were attended by about 50 active participants (not 
counting non-participating observers), out of a total meeting 
attendance that had dwindled to about 120. Clearly a reorga¬ 
nization and restructuring of the SEC was needed. 

A reorganization was initially proposed at the October, 1993 
PASC meeting in Bethesda, and has been more or less hotly 
debated since then. We finally put out an official letter ballot 
to the then current voting members of the SEC. The results 
were in before our April, 1995 meeting in Irvine, CA, which 
broke the issue into three main questions: 

• Should the basic reorganization happen? 

• Should the SEC Functional Chairs (formerly called Vice 
Chairs) be granted continued SEC voting status? 

• Should the PMC continue to exist? (The Project Manage¬ 
ment Subcommittee reviews projects and makes recom¬ 
mendations to the whole SEC, but has no absolute 
authority of it own). 

I have paraphrased these a bit for simplicity, but the ballot 
resulted in the approval of all three questions. However, it 
was generally accepted that the precise organization speci¬ 
fied in the ballot was not perfect, and since this issue had 
been so contentious, I announced in January that the reorga¬ 
nization would not take effect until after the April meeting, 
and that motions could be made to “fine tune” the organiza¬ 
tion during the April SEC meeting itself. There was consid¬ 
erable debate, and strict Robert's Rules of Order were 
followed, but in the end, there were only three real changes 
made: 

• a very small number of projects were rearranged under the 
new working groups. 

• the office of Coordination Functional Chair was removed. 

• the structure of the PMC was changed to allow up to half 
the members to be from outside the new SEC, and to allow 
the PMC Chair a vote on the SEC. 

The last point is particularly important since it allows PASC 
members who do not have a vote on the new SEC to have a 
significant voice in the project approval mechanism. I sin¬ 
cerely urge people to consider participating through this 
mechanism. 

After all this preamble, here is the new PASC organization: 

PASC 1995 Organization 

System Services 1003.1 (standard) 

1003.1a (addendum) 

1003.1b (RT- std) 


Shell and Utilities 

1003.1c (threads) 

1003.Id (more RT) 

1003. If (TFA) 

1003.1h (SRASS) 

1003.1i (corrigenda) 
1003.1j (advanced RT) 
1003.1k (Serial media) 
1003.2 (standard) 

System Administration 

1003.2a (standard) 

1003.2b (more S & U) 
1003.2d (batch) 

1003.2e (Serial media) 
1387.1 (SA Interfaces) 

Language Bindings 

1387.2 (standard) 

1387.3 (User mgmt) 

1387.4 (print) 

1003.5 (standard) 

Security 

1003.5a (more Ada) 
1003.5b (AdaRT) 

1003.5c (XTI) 

1003.5d (sockets) 

003.9 (standard) 

2003.5 (test methods) 
1003.1e (system APIs) 

Profiles 

1003.2c (S&U) 

1003.22 (framework) 
1003.0 (POSIX Guide) 

Test Methods 

1003.10 (Supercomp) 

1003.13 (RT profiles) 

1003.14 (multi-proc) 
1003.18 (POSIX profile) 

1201.2 (drivability) 

1003.3 (standard) 

Distributed Services 

2003r (.3 revision) 

2003.1 (standard) 

2003.2 (.2 & .2a TMs) 
2003.4 (RT TMs) 

1326 (standard) 

1326.1 (standard) 

1326.2 (standard) 

1328 (standard) 

1328.1 (standard) 

1328.2 (standard) 

1003.1 g (XTI/Sockets) 


1003.21 (RT Dist. Comm) 
1224 (standard) 

1224.1 (standard) 

1224.2 (standard) 

1238.1 (standard) 

1238.2 (standard) 

1327 (standard) 

1327.1 (standard) 

1327.2 (standard) 

1351 (standard) 

1353 (standard) 


AUGUST 1995 ,'logifl \ 43 


STANDARDS 


[This table was purposely terse so that it could fit on a single 
page or slide. A complete listing of the PASC projects is pro¬ 
vided as an addendum to this article for reference purposes. 
For those of you who are not yet comfortable with the num¬ 
bering changes, I have included both the old and new num¬ 
bers of the affected projects, so the list looks a bit longer than 
you may have expected.]. 

One of the major ramifications of this new working group 
structure is the changes (both direct and indirect) in the SEC. 
Obviously the SEC becomes much smaller. However, it must 
be emphasized that the SEC meetings are open, so anyone 
may attend. It is my intention to allow everyone present the 
chance to speak, but I reserve the right to place reasonable 
limitations on the time a non-member may hold the floor. 
Besides the right to vote, SEC members are also the only 
ones who can make a formal motion. 

The new SEC has the following structure: 

Voting Members of the SEC: 

8 New Working Group Chairs 
4 SEC Officers (Chair, V. Chair, Secretary, Treasurer) 

3 Functional Chairs (Balloting, Logistics, Interpretations) 

1 Project Management Committee Chair 

4 Institutional Representatives (rotating membership) 

This yields a total of 20 votes in the reorganized SEC. How¬ 
ever, one person is currently both the Vice Chair and Secre¬ 
tary, but only votes once, so there are effectively only 19 
votes. This is quite a change from the 36 to 38 we had a year 
or two ago. 

There used to be six Institutional Representatives (IRs) 
before the reorganization, but since the number of voting IRs 
cannot exceed 25% of the total non-IR voting membership, it 
had to be reduced to four. As stated above, we will continue 
to allow all IRs (and anyone else) to attend the SEC meetings, 
but only four will be allowed to vote. The IRs did not wish to 
select which of them would be allowed to vote, so the SEC 
held a ballot to determine the voting IRs. The two highest 
vote getters would sit for two years and the next two would 
have one year terms. Another election will be held in one 
year for the two expiring positions. The two expiring IRs 
may (and probably will) stand for re-election, but any other 
IR who so wishes may also try for the next term, which will 
be a full two years. Then every year we will hold another 
election for the two expiring two year terms. 

The vote was very close, and in fact there was a tie for sec¬ 
ond and third, so a coin toss was used to select which IR 
would receive a two year term and which the one year term. 
As a result, EurOpen and X/Open won the 2 year terms, 
while USENIX and OSSWG (a US Navy user group) received 
the one year terms. I wish to express thanks for the input and 
support from all the other IRs and invite them to continue to 


attend our meetings and stand for election at the April, 1996 
meeting. 

It is our intention that the SEC will become mostly an 
administrative body with the bulk of the technical decisions 
being made in the new “large” working groups. Some peo¬ 
ple have dubbed these the “super groups,” but that is strictly 
unofficial. 

Another result of the reorganization is that the steering 
committees all disappear. Their work of coordinating the 
various interacting projects will now be done in the plenary 
sessions of the new working groups. A few special cases 
(such as testing amendments and security) will be worked 
out between the groups. 

It is our hope that these changes will result in faster and 
more efficient SEC meetings, but the primary benefits 
should be to reduce the administrative work that must be 
done by each project “leader.” Nothing was mandated, but 
it was suggested that each working group have a vice-chair 
for each project, which may effectively be the chair, or the 
technical leader for that project. With the new organization, 
only the eight working group chairs should have to deal 
with the paperwork involved in the standards process, thus 
leaving other people more time to do the technical work. 

Only time will tell how effective this new organization is, 
but it is an evolving process after all, and more changes are 
probably already looming in the future. 

PASC Projects 

1003.0 Guide to POSIX Open System Environment 
1003.1 System API C-B inding 

(Standard approved 9/90) 

. 1 a System API Extensions - C-B inding 
(PAR revised 3/94) 

.lb New # of old 1003.4-Real Time 
(Standard approved 9/93) 

. 1 c New # of old 1003.4a - Real Time Threads 
(Standard approved 6/95) 

. 1 d New # of old 1003.4b - Real Time API 
Extensions 

. 1 e New # of old 1003.6.1 - Security API 
Extensions 

. 1 f New # of old 1003.8 - Transparent File Access 
. 1 g New # of old 1003.12- Protocol Independent 
Interfaces 

.lh Reliable, Available, Serviceable Systems 
(PAR approved 9/94) 

.li Technical corrections to 1003.lb-1993 
(Standard approved 6/95) 

. 1 j Advanced Realtime Extensions - C 

(PAR approved 10/94) 

.lk Serial Media APIs (PAR approved 6/95) 


44 ; login : vol. 20 . no. 4 


STANDARDS 


.1 LIS Language Independent form of 1003.1 

1003.11 

Transaction Processing - Support withdrawn by 


(see PI 372) 


SEC 4/93 



1003.12 

Protocol Independent Interfaces - C 

1003.2 

Shell and Utilities (IEEE Standard approved 


[became 1003. lg] 


9/92) 

1003.13 

Real Time Application Profiles 

.2a 

User Portability Extensions 

1003.14 

POSIX Multiprocessing Application Environment 


(published with 1003.2) 


Profile 

,2b 

Shell and Tools - Corrections and Extensions 

1003.15 

Batch Queuing Extensions (to be split, see 


(PAR revised 3/92) 


1003.2d for .2 part) 

.2c 

New # of 1003.6.2 - Security Shell & Utility 

1003.16 

System API - C-Binding to the LIS 


Extensions (PAR 9/93) 


(PAR withdrawn 7/93) 

.2d 

New # of part of 1003.15 - Batch Shell & 

.16a 

System API Extensions - C-Binding to LIS 


Util Extensions 


(PAR withdrawn 7/93) 

.2e 

Serial Media Shell and Tools 

1003.17 

Directory Services [replaced by 1224.2,1326.2, 


(PAR approved 6/95) 


1327.2, 1328.2] 

1003.3 

General POSIX Test Methods 

1003.18 

POSIX Environment Platform AEP 


(Standard approved 3/91) 


(the “minimum” POSIX profile) 

.3.1 

Test Methods for System API 

1003.19 

Fortran 90 Binding to 1003.1 


(approved 10/92 - see 2003.1) 


(Support withdrawn 9/93) 

.3.2 

Test Methods for Shell and Tools (see 2003.2) 

1003.20 

Real Time Ada Bindings (PAR approved 7/91) 

1003.4 

Real Time Extensions [published as 1003.1b] 


[became 1003.5b] 


(Standard approved 9/93) 

1003.21 

Real Time Dist Systems Communications 

.4a 

Real Time - Threads Extension 


(PAR approved 3/93) 


[will be published as 1003.1c] 

1003.22 

Guide to Open Systems Security Framework 

4b 

Real Time System API Extensions 


(PAR approved 3/93) 


[becomes 1003.1 d] 

1201.1 

Interfaces for User Portability 

1003.5 

Ada Binding to System API (9945-1) 


(support withdrawn 9/94) 


(Standard approved 6/18/92) 

.2 

Recommended Practice on Driveability 

.5a 

Technical corrections to 1003.5-1992 

.X 

Direct Balloting of X Library 

.5b 

Ada Realtime Bindings (old .20 for .4 & .4a) 


(never officially submitted) 


(PAR approved 7/91) 

1224 

OSI Abstract Data Manipulation - LIS 

.5c 

Ada Binding for Protocol Ind. Interfaces - XTI 


(Standard approved 3/93) 


(PAR approved 10/94) 

.1 

OSI X.400 Messaging API -LIS 

1003.6 

Security Extensions (original document split in 


(Standard approved 3/93) 


2 parts) 

.2 

Directory Services API - LIS (Std approved 3/93) 

.6.1 

Prot, Audit, & Control Interface - Amend to 

1237 

Support withdrawn by the SEC 10/90 


1003.1 [see 1003.1e] 

1238 

Common OSI API 

.6.2 

Protection and Control Utilities - Amend.to 

.1 

OSI FTAM API (PAR revised 6/94) 


1003.2 [see 1003.2c] 

1326 

Test Methods for 1224 (Standard approved 3/93) 

1003.7 

System Administration Interface [see 1387.1 - 

.1 

Test Methods for 1224.1 


changed 10/93] 


(Standard approved 3/93) 

.7.1 

Sys Admin Print Management 

.2 

Test Methods for 1224.2 


(PAR approved 1/92) [see 1387.4] 


(Standard approved 3/93) 

.7.2 

Sys Admin Software Administration 

1327 

OSI Abstract Data Mn API - C-Binding 


(PAR app 1/92) [see 1387.2] 


(Standard approved 3/93) 

.7.3 

Sys Admin - User & Group Account 

.1 

OSI X.400 Messaging API - C-Binding 


Management [see 1387.3] 


(Standard approved 3/93) 

1003.8 

POSIX Transparent File Access Interface 

.2 

Dir Services API - C-Binding 


(see 1003. If) 


(Standard approved 3/93) 

.8a 

Shell and Tools: TFA Utilities 

1328 

Test Methods for 1327 (Standard approved 3/93) 


(PAR approved 1/92) 

.1 

Test Methods for 1327.1 

1003.9 

Fortran 77 Bindings to POSIX 


(Standard approved 3/93) 


(Standard approved 6/92) 

.2 

Test Methods for 1327.2 

1003.10 

Supercomputing Appl. Environment Profile 


(Standard approved 3/93) 


(Standard approved 6/95) 

1351 

OSI API - ACSE & Presentation Layer 


(Standard approved 9/94) 
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1352 LIS Test methods for 1351 

1353 OSI API - ACSE & Presentation (C-Binding) 

(Standard approved 9/94) 

1354 C Language Test Methods for 1353 

1372 System Interfaces (old 1003.1 in LIS form) 

1387.1 System Administration Umbrella document 
.2 System Admin. Software (old # 1003.7.2) 

System Admin. User / Group 

(new number of 1003.7.3) 

.4 System Admin. Printing (new number of 
1003.7.1) 

2003 Test Methods for OSE (revision of 1003.3-1991) 
(PAR approved 7/92) 

.1 Test Methods for System API 

(Standard approved 10/92) 

.2 Test Methods for Shell and Tools (in recirculation 
ballot) 

.4 Test Methods for Real Time Extensions 
(PAR approved 1 /94) 

.5 Test Methods for System API - Ada Binding 
(PAR approved 9/94) 

POSIX.O: Guide to POSIX OSE 

Kevin Lewis <klewis@granpa.enet.dec,com> reports on the 
April 24-281995 meeting in Irvine, CA 

Draft 18 of the POSIX.O guide was submitted to the IEEE 
Review Committee (RevCom) at its March 15 meeting. Rev- 
Com noted that one change was made to the draft without 
that change being circulated to the ballot group. Thus, much 
to the appreciation of the fatigued ballot coordinator who is 
also the author of this snitch, RevCom gave approval condi¬ 
tional upon the recirculation of the change and upon the 
receipt of no new objections. 

This recirculation was completed on April 24. One new neg¬ 
ative ballot was submitted but this ballot simply restated an 
objection that had been previously been circulated. The bal¬ 
lot summary resulting from this last recirculation is as fol¬ 
lows: 

58 affirmative 
9 negative 
9 abstentions 
93% return 
86% affirmative 

At this point, the ballot coordinator has made contact with 
the IEEE RevCom Secretariat to review the recirculation 
results. It is the humble (and I believe accurate) opinion of 
this writer that the conditions set by RevCom on POSIX.O 
have been met and full approval should be rapidly forthcom¬ 
ing. The next step, upon receipt of full approval, is submittal 
of draft 18 to JTC1 for final balloting. 


The future meeting plan for POSIX.O is to have a one day 
meeting at the July meeting in Nashua to declare victory and 
for the group to enjoy a dinner together. As far as future 
work is concerned, a study group on User Profiles has 
spawned out of POSIX.O and is now operating on its own. It 
appears that it will become a working group by the end of 
1995. 

I think it is now safe to say the POSIX.O Guide Project is 
done (or to quote Jason Zions, “It’s cooked!”) 

Report on POSIX. 1: System API 

Shravan Pargal <pargal@ironwood.cray.com> reports on 
the April 24-28,1995 meeting in Irvine , CA 

This meeting in Irvine was a busy one for the POSIX.la 
working group. Draft 12 of POSIX.la was sent out to the bal¬ 
lot group in November, with the ballot closing on March 
15th, 1995. Ballots were in and needed to be worked on dur¬ 
ing this meeting. The following were the primary agenda 
items at this meeting: 

• Removable media plenary 

• Ballot resolutions 

The first issue tackled after the meeting was called to order 
was a plenary with the removable media group. Chuck 
DeBaun (Fermilab) presented a proposal to the working 
group for a set of functions for serial media control. The pro¬ 
posal covered open ( ), close (), read ( ), and write ( ) 
issues related to serial media. In addition, there was a pro¬ 
posal for additional interfaces to formalize and expand 
ioctl like functions (to be known as mtio functions) as 
related to serial media. 

The working group split up into smaller groups of two or 
more members to tackle the large number of ballots that 
needed resolutions. Each group was assigned a chapter to 
work on to resolve “easy” ballot requests. In addition the 
groups tried to sort the ballots by issue, forming sub-groups 
within each chapter. The groups then brought lists of issues 
back to the working group as a whole for discussion. After 
working on ballot classification and resolution for two days, 
the group discussed the state of the returned ballots. Ballots 
returned seemed to be split into three roughly equal chunks: 
checkpoint/restart, resource limits, and everything else. The 
working group decided (thanks to a suggestion from Nick 
Stoughton and Chuck Karish), to split the POSIX.la project 
authorization request (PAR) into three PARs, submitting 
checkpoint/res tart and resource limits as separate standards. 
Two new PARs will be submitted to the SEC 45 days in 
advance of the next meeting. However since the earliest this 
could be approved is in July, the working group decided that 
a final decision would be held off until the July meeting. 
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In between ballot resolution, discussions were held on pro¬ 
posals for getshconf () submitted by David Willcox and 
signals submitted by Alan Rowe. The getshconf () inter¬ 
face was defined to meet a need to separate POSIX.l and 
POSIX.2 symbols and yet be able to get one from the other 
in a portable form. The signals discussion will continue 
through e-mail. 

The POSIX.l a WG will continue to work on resolving ballot 
objections and interpretations resulting from the Draft 12 
ballot. A final decision to go ahead and form the new project 
teams for checkpoint/restart and resource limits will be 
made at the next meeting. 

Report on POSIX.lg: Protocol 
Independent Interfaces 

Chris Harding <charding@datlog.co.uk> reports on the 
April 24-28,1995 meeting in Irvine , CA 

The POSIX.l2 group (now known as POSIX.lg) was formed 
to standardize a protocol-independent interface for process- 
to-process communication within POSIX. Two candidate 
interfaces were presented to it: the X/Open Transport Inter¬ 
face (XTI) and Berkeley sockets. In spite of intense - some¬ 
times very heated - discussion, the group could not choose 
between them. Also, it felt that both of these interfaces were 
at too low a level, and that a simpler interface was really 
what was needed. 

In its early days, the group was well-attended. It had plenty 
of resources, and thought that it had plenty of time. It 
decided to specify a Detailed Network Interface (DNI), 
which would be either XTI or sockets, and a Simple Net¬ 
work Interface (SNI), which would be a new interface that it 
would develop. 

In line with then current POSIX practice, it would have to 
create a language-independent specification (LIS) and test 
methods for the SNI and the DNI, and create a new C lan¬ 
guage binding for the SNI, as well as tidying up the DNI C 
language binding. 

Attendance at POSIX meetings dwindled. POSIX. 12, like all 
the other groups, suffered from this. Completing the pro¬ 
gram within a reasonable time became impossible. 

The group therefore decided to focus its efforts: 

• The SNI was deferred until the DNI was done. 

• The argument between XTI and sockets was cut short; the 
group decided to standardize both C language bindings, 
and to create a single LIS for them. 

• Because no one else in POSIX would do it, the group also 
decided to standardize poll () and select () , which are 
needed by many applications of XTI and sockets. 


• XTI was to be specified in conjunction with OSI and Inter¬ 
net protocols. The sockets interface was to be specified in 
conjunction with OSI and Internet protocols, and for local 
inter-process communication. 

• Test methods for XTI were available from X/Open; these 
would have to be tidied up, and new test methods for sock¬ 
ets and the LIS would have to be written. 

On this basis, the group made good progress. 

The POSIX Sponsor Executive Committee then dropped its 
requirements to produce LIS and test methods for POSIX 
specifications. The POSIX. 12 LIS was by this time nearly 
complete. The group decided to continue with its LIS 
(although it was not clear exactly how this would eventually 
be published). No work had been done on test methods, so 
the group was happy not to have to worry about them any¬ 
more. 

At about this time, the name of the group was changed to 
POSIX. lg. 

A ballot group was formed which is much larger than the 
working group. It reviews drafts but does not meet. The 
POSIX. lg working group has been fortunate because the 
ballot group contains a number of people who have been 
prepared to spend considerable time and effort in reviewing 
the drafts. 

A draft (draft 4.0) containing the two C language bindings 
and the LIS was prepared and submitted to ballot. There 
were 1188 ballot objections and comments on draft 4.0, and 
it was well short of the 75% approval that is needed for it to 
be accepted as an IEEE standard. 

By the time of the April 1995 POSIX meeting, the standard 
had been refined in ballot through draft 4.1, which received 
452 objections and comments, draft 5.0 (299 objections and 
comments) and draft 6.0 (165 objections and comments). 

It had also been slightly expanded in scope, since several 
ballot objections called for functionality to be added. The 
main additions were: 

• two new sockets functions that are needed because POSIX 
does not include all of the features of BSD UNIX. 

• getaddrinf o ( ) translates the name and/or location of a 
service into socket addresses and associated information. 

•is f dtype () determines whether a file descriptor is asso¬ 
ciated with a socket. 

• sockatmark () determines whether a socket is at the out- 
of-band mark. 
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• various Internet address-resolution functions, such as 

gethostbyname(). 

• support for a minimal 7-layer OSI stack (mOSI) under XTI. 

The question of supporting New Generation IP has been 
raised, but the group felt that this was not yet sufficiently 
mature for standardization. 

There were just four regular (more or less) attendees at the 
April meeting: Reed Adams, Greg Bussiere, Steve Case (the 
group vice chair), and Chris Harding. A number of people 
who had been strong contributors at previous meetings were 
unfortunately unable to come this time, because of funding 
limitations, pressure of other work, or job changes. They 
included Bob Durst (the group chair), Mike Karels, Karen 
Olsen, Kurt Matthys, Keith Sklower, and Steve Wise. 

The meeting was almost exclusively devoted to resolution of 
ballot comments. 

There have now been a total of over two thousand comments 
and objections. It is much easier to handle them on line than 
on paper. The group has increasingly been making use of 
laptops, with megabyte ballot-comment files being passed 
around on floppies. This time, all work was computer-based, 
and the comments were never even printed out. 

There have been progressively fewer comments and objec¬ 
tions on each draft (a good sign!). This time, in spite of the 
reduced attendance the group produced provisional resolu¬ 
tions for almost all comments on the current draft, and also 
cleared up most of the comments that had been deferred 
from previous drafts (there were quite a few of these - par¬ 
ticularly from the first balloted draft). 

The most controversial technical issue has been whether XTI 
and sockets should both be required, or whether a conform¬ 
ing implementation can support just one of them. The ballot 
group was polled some time ago on this, and was split 50/50. 
A compromise was reached: XTI and sockets are specified as 
separate options, but conforming implementations must sup¬ 
port both. A profile for a minimal realtime implementation, 
for example, might however require just one of the options. 
(An implementation could then conform to the profile with¬ 
out conforming to the base standard - an interesting situa¬ 
tion.) There were a number of objections against this 
compromise, all of which called for the requirement to sup¬ 
port both XTI and sockets to be dropped. However, other bal- 
loters had said that they would object if the requirement 
were dropped. It transpired that dropping the requirement 
would turn more “yes” votes to “no” than it would turn “no” 
votes to “yes.” The requirement was therefore kept. 

One major decision was to move the LIS into an informative 
annex. The ultimate fate of the LIS is still not clear. It pro¬ 


vides a logical basis for putting forward XTI and sockets as 
parallel interfaces. Also, it provides a complete specifica¬ 
tion of how the API relates to the underlying protocols; 
nether the XTI nor the sockets specification does this. But it 
does not add anything to the definitions of the XTI and sock¬ 
ets functions. And there have been objections to including it 
as normative material, even though the C language bindings 
specifications have always had priority in case of any con¬ 
flict. 

Another question that was resolved concerns the form of the 
draft. There is a POSIX Document Structure Plan, which 
calls for drafts to be laid out as though they were to be 
printed as part of the complete POSIX document set. This 
would probably mean POSIX.lg starting at chapter eighty¬ 
something. Its purpose is to ease the integration of all the 
parts of POSIX. But integration is proceeding one project at 
a time, and the turn of POSIX. lg will not come for some 
years (no one is quite sure exactly when it will be). The 
organizations that fund participants’ attendance at POSIX. lg 
meetings are not prepared to continue this funding indefi¬ 
nitely, and the group wants to be done by the end of this 
year. The current draft is organized as a self-contained doc¬ 
ument (but with one chapter that describes changes to 
POSIX. 1). The group now intends to submit it to the IEEE 
Standards Board in this form. 

With the changes decided on at the meeting, over 75% of 
balloters should vote affirmatively. 

But there will still be a further two or (more probably) three 
ballot recirculations. These will tidy up loose ends, and 
ensure that balloters are happy with the actions that have 
been taken to meet their objections. The first of them will be 
a 10-day recirculation starting on June 19th. A subsequent 
recirculation could take place between the July and October 
POSIX meetings. If necessary, there could be a further recir¬ 
culation before the end of the year. 

Report on POSIX.21: Realtime 
Distributed Systems Communication 

Craig Meyers <bcm@SEI.CMU.EDU> reports on the April 
24-28, 1995 meeting in Irvine, CA 

The goal of the POSIX.21 working group is to develop a lan¬ 
guage-independent specification (LIS) and Ada language 
binding for interprocess communication in the realtime dis¬ 
tributed systems domain. The group is expected to address 
realtime needs in the following areas: protocol manage¬ 
ment, endpoint management, connection management, uni¬ 
cast data transfer, multicast data transfer, multicast group 
management, transaction services, event and error manage¬ 
ment, and performance monitoring. The interface will also 
provide support for the use of priorities, synchronous and 
asynchronous interactions, and the ability to bound the 


48 ;login: vol. 20 . no 4 


STANDARDS 


blocking that a calling task is able to accept through the use 
of timeouts. Similar to POSIX.lg, the interface will be 
developed in a protocol-independent manner with mappings 
provided to existing protocols. It is expected that a mock 
ballot of the LIS will be initiated after the July POSIX meet¬ 
ing. 

The following is a summary of the major topics discussed at 
this meeting: 

• buffer management, including allocation of buffers to 
application vs. service provider space. 

• endpoint management; purge operations were removed 
and hard vs. graceful deletion of an endpoint was dis¬ 
cussed. 

• directory services LIS and models, including location- 
independent and location-dependent. 

• event management; including ways in which the applica¬ 
tion becomes aware of events (poll vs. callback, for exam- 
pie). 

• overall data transfer models in an attempt to harmonize 
individual models (e.g., unicast, multicast, and broadcast) 
within a larger framework. 

• performance measurement; several issues were resolved. 

• prototyping; those interested in this topic had separate 
meetings and discussed implementation considerations for 
the initial work. 

A transcription of the minutes are available by anonymous 
FTP from ftp.sei.cmu.edu in the file pub!posixJadmin!min- 
95-04. Persons interested in working with the group are 
requested to contact Craig Meyers at bcm@sei.cmu.edu. 

Report on POSIX.4 

Joe Gwinn <GWINN@SUD2.ED.RAY.COM> reports on the 
April 24-28,1995 meeting in Irvine , CA 

What is the POSIX.4 Working Group doing? 

The big news is that as part of the general reorganization of 
the POSIX working groups, the POSIX.4 Working Group no 
longer exists, having been largely replaced by the newly 
constituted “System Services Working Group” (SSWG), as 
of the end of the April POSIX meeting. SSWG is composed 
of the antebellum POSIX. 1, POSIX.4, POSIX.8, and SRASS 
Working Groups. SSWG retains all the documents of the old 
POSIX.4 WG except POSIX. 13, which goes to the new “Pro¬ 
files Working Group” (which consists largely of the old 
POSIX.O WG). The July meeting will be the first under the 


new organization. Expect some chaos. In spite of this inter¬ 
nal organizational motion, the same people are working on 
the same documents as before. 

The POSIX.4 WG has five major projects: POSIX. 1c, or 
pthreads (formerly known as POSIX.4a), POSIX.Id (for¬ 
merly known as POSIX.4b), POSIX. li, POSIX. lj (informally 
known as “POSIX.4d”), and POSIX. 13, discussed below. 

IEEE Std 1003.lb-1993, the merger of 1003.1-1990 and the 
realtime extensions POSIX.4, is now available from the IEEE 
(800-678-4333 in Canada and the USA, 1 -908-981-1393 
elsewhere, and 1-908-981-9667 by fax) as a published, 
bound 590-page book, for almost $100 US. Ouch! Anyway, 
the IEEE accepts credit card phone orders. 

POSIX.lc (pthreads) passed International Standards Organi¬ 
zation (ISO) Committee Document (CD) balloting in Febru¬ 
ary 1995 with only one editorial comment, and Draft 10 will 
be submitted unchanged to the IEEE Standards Board for 
approval at their June 1995 meeting. Approval appears 
likely, at last. (Editor’s note: POSIX.l c was approved at this 
meeting). After approval, POSIX. lc will also be merged into 
POSIX. 1-1990 (or, more likely, IEEE Std 1003.1b-1993), 
which will take a year to get to a published merged book, if 
history is any guide. This published standard will likely be 
called “IEEE Std 1003.1c-1995,” and, with luck, will be 
available in late 1996. 

POSIX.4b (now POSIX.Id) is in ballot resolution, which is 
almost complete, except in the areas under discussion with 
the members of the Common Reference Ballot. Interrupt 
Control has been a particularly contentious area. The cur¬ 
rent plan is to recirculate after the April 1995 POSIX meet¬ 
ing, if possible. 

POSIX.Id, around 130 pages in length, contains a number of 
realtime interfaces and options that arrived too late to be 
included in 1003.lb-1993 (which itself consists of POSIX.l 
and POSIX.4 combined). The major new interfaces and 
options are: spawn (), a functional merger of fork () and 
exec (), needed both for efficiency and to allow use on 
platforms lacking memory management hardware, a spo¬ 
radic-server scheduling policy, used to prevent asynchro¬ 
nous high-priority processing from totally consuming the 
computer; epu-time clocks and timers, used to both measure 
and bound use of epu by processes; devctl (), the succes¬ 
sor to the ioctl () of classic UNIX; Interrupt Control, a set 
of interfaces intended to allow direct application-level con¬ 
trol of devices such as array processors and radar signal pro¬ 
cessors; and Advisory Information, a set of interfaces that 
allow an application to declare to the kernel that, for 
instance, a specified file will be read sequentially, allowing 
the kernel to optimize performance. A number of existing 
interfaces are also being augmented by the addition of vari¬ 
ants supporting timeouts. 
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POSIX.li (also known as “POSIX.4 technical corrections”) 
went to ballot in November 1994, and is currently in ballot 
resolution. ( Editor’s note: this standard too was approved at 
the June 1995 IEEE RevCom meeting, making it the fastest 
standard on record from Project Inception in July 1994 to 
completed standard in June 1995!) 

POSIX.li consists of correcting the POSIX.4 interfaces to 
remedy clashes detected when POSIX.4 was merged into 
POSIX. 1-1990 to yield POSIX.lb-1993, as well as minor 
problems discovered by early implementors of POSIX.lb- 
1993. POSIX.li is a fast-track effort with a very limited and 
specific scope. As the changes are small, simple, and few, 
approval is expected to be rapid, at least as POSIX under¬ 
stands the term. 

“POSIX.4d” (now POSIX.lj), approved as a project by the 
Sponsor Executive Committee (SEC) at the October 1994 
POSIX meeting, is being polished in the POSIX.4 WG. Draft 3 
underwent mock ballot at the January 1995 POSIX meeting, 
and Draft 4 has been sent out in the March 15th POSIX mail¬ 
ing. POSIX. lj was voted out to ballot at the April 1995 
POSIX meeting. Ballot will be after the July 1995 POSIX 
meeting. Watch out for the ballot group invitation from the 
IEEE. I will announce the opening of the ballot group when 
dates are available. Actual first ballot is scheduled for 8 Sep¬ 
tember 1995 to 8 October 95; the ballot group will therefore 
close something like 1 September 1995. 

POSIX. lj, 73 pages, contains a number of realtime interfaces 
and options that arrived too late to be included in POSIX.Id. 
The major new interfaces and options are: Typed Memory, a 
set of interfaces supporting the mmap() -like mapping of 
diverse kinds of physical memory (e.g., SRAM, DRAM, 

ROM, EPROM, EEPROM) via multiple and/or diverse physi¬ 
cal paths used to access special hardware and memory via 
attached VME busses; nanosleep_abs (), a high-resolution 
sleep () allowing the user to specify when to awaken, 
rather than how long to sleep; Barrier Synchronization, a set 
of interfaces intended to support efficient implementation of 
parallel DO/FOR loops on massively parallel computers; 
Reader/Writer Locks, used to allow efficient parallel access 
to data in situations where reads vastly outnumber writes; 
Spinlocks, a very fast synchronization primitive for use on 
shared-memory multiprocessors; and Persistent Notification 
for Message Queues, an option for POSIX.lb-1993 Message 
Queues. 

POSIX. 13 ballot resolution is nearly complete, and POSIX. 13 
will probably be recirculated after the April 1995 POSIX 
meeting. 

POSIX. 13,100 pages, is a family of four related realtime pro¬ 
files ranging in size from the very small through a full-fea¬ 
tured platform conforming to essentially all of POSIX.lb- 
1993 (POSIX.l plus POSIX.4) and POSIX.lc (threads), with 


realtime options chosen. The smaller profiles specify just 
that subset of POSIX interfaces needed to “clothe” widely- 
used small kernels such as pSOS, WindRiver, and VRTX32, 
and the ORKID interface standard, which, although very 
similar in function, differ greatly in interface details. As a 
matter of interest, there are more of these small kernels in 
UNIX systems than there are UNIX kernels because, for 
instance, many I/O controllers and peripherals themselves 
use one of these small kernels. Standardization of these 
interfaces will yield the same benefits for embedded and 
realtime as standardization of UNIX did for workstations. In 
addition, the POSIX. 13 interfaces are chosen to allow multi¬ 
computer distributed systems to be built, such as those used 
in factory automation. Such systems are typically set up as a 
hierarchy, with a few large-profile machines at the top, and a 
large number of smaller profile machines at the bottom con¬ 
trolling this or that piece of machinery, perhaps with an 
intermediate layer of supervisory machines between top and 
base, all communicating with peers, superiors, and subordi¬ 
nates, as needed. 

A number of new items, as yet un-numbered and homeless, 
are under consideration, including a Trace Interface, and 
various issues relating to time and clocks. 

Trace Interface. The purpose of these interfaces is to allow 
the collection and presentation of trace logs of application 
calls on the operating system, I/O activity, user-defined 
events, and the like, with an eye to debugging user code 
running at essentially full speed. This is certainly a require¬ 
ment for realtime applications. A number of vendors have 
come forward with implementations, and there has been 
great interest in coming up with standard APIs and, to some 
extent, log file contents. The proposed trace interfaces do 
not in the least resemble standard inspect-and-change 
debuggers, and require no kernel knowledge to use. The 
feeling of the vendors appears to be that a trace API would 
allow them to sell something very much like their existing 
trace tools beyond their present user base. The details are 
changing daily; stay tuned. 

Time and Clocks. The addition of some new kinds of clock 
to the list in POSIX.lb-1993, section 14.1.4, which currently 
defines CLOCK_REALTIME and TIMER_ABSTIME, are 
under discussion. The new kinds of clock are tentatively 
named CLOCK_SYNCHRONIZED and CLOCKJFUNDA 
MENTAL. Clock kinds are in effect qualitative descriptions 
of what an application writer can and cannot expect of a 
clock; few numerical limits are to be specified. 

CLOCK_REALTIME specifies only that the resolution be 
20 milliseconds or finer, a complex way of saying that one 
second resolution isn’t quite good enough for realtime. The 
value was chosen to allow platforms with the usual 100-Hz 
or 60-Hz clock tick rate to satisfy the requirement. 
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TIMER_ABSTIME is used to cause a timer to be absolute 
(wait until 10:00), rather than relative (wait 10 seconds). 

CLOCK_SYNCHRONIZED gives user-controlled access 
to a local (to a platform) clock synchronized with an exter¬ 
nal clock (or set of clocks). Synchronization could be with a 
local GPS receiver, or by the Network Time Protocol (NTP) 
to a network timeserver. The details are implementation 
dependent. Synchronized clocks are allowed to run slightly 
fast or slow, and to make small (up to one second) jumps 
forwards or backwards, to account for leap seconds and the 
like. If NTP is active on a workstation, the standard get- 
timeofday <) returns synchronized time; the point of hav¬ 
ing a named clock kind is to allow the user to express the 
true requirement. 

CLOCK_FUNDAMENTAL gives user-controlled access 
to a local (to a platform) clock whose value steadily and 
smoothly increases. CLOCK_FUNDAMENTAL is uni¬ 
form, monotonic, and continuous (to the resolution of the 
clock implementation), and also allows direct implementa¬ 
tion of Ada95 (section D.8) Monotonic Time. Fundamental 
time always runs at the same (perhaps slightly inaccurate) 
rate, and never jumps. It may, however, give the same value 
twice, if called faster than the tick rate of the clock imple¬ 
mentation. A clock cannot be both fundamental and syn¬ 
chronized, although a fundamental clock and a 
synchronized clock can certainly be approximately equal. 
Fundamental time is useful when the issue is the measure¬ 
ment, tracking, or prediction of the trajectory of a physical 
object; and for the accurate measurement of intervals. The 
details are implementation dependent. 

Under discussion is which clock the various time-related 
POS1X. lb-1993 APIs will follow, where no argument to 
specify a clock is provided. Relative timers (wait 10 sec¬ 
onds) will most likely use or act like they use 
CLOCK_FUNDAMENTAL, while absolute timers (wait 
until 10:00) will likely use CLOCK_SYNCHRONIZED. 
The handling of pthread_cond_timedwait( ) is an 
issue, as it uses absolute time to achieve relative semantics. 

Report on POSIX System Administration: 
Software Administration 

Jay Ashford <ashford@austin.ibm.com> reports on the 
April 24-28,1995 meeting in Irvine, CA 

The April 1995 meeting of the POSIX Software Administra¬ 
tion group marked an historic event - PI 387.2 became the 
first POSIX system administration project to complete its 
work. System administration in general has been a big chal¬ 
lenge for standardization due to the exceptionally rich and 
diverse heritage of administrative tools, techniques, and 
policies. Blending these together into a coherent standard is 
a very challenging task. 


Software administration is certainly one of those areas with 
a rich and diverse legacy. PI387.2 provides the basis for 
standardized software administration. It includes a media 
organization for install images, along with commands to 
install, remove, configure, and verify software. Commands 
are also included to create distribution images and to merge 
distribution images. Along with these commands is an 
extensive description of their behavior. Provision is also 
made for tracking what software is installed and what its 
level is. All of these commands provide distributed function 
so that installation (removal, configuration, etc.) may be 
directed on one system to occur on any number of systems 
throughout a network. 

Key to this process is the organization of the distribution 
images and the installed software. The units include files, 
filesets (groups of files), and products. This is made a bit 
richer by the use of sub-products (collections of filesets and 1 
or other sub-products within a specific product) and bundles 
(collections of filesets, sub-products, products, or other bun¬ 
dles anywhere within a distribution or installed software). 

One very valuable addition to this effort is a set of conces¬ 
sions to operating systems not based on POSIX. 1 and 
POSIX.2. In particular, there are exception conditions that 
allow such systems as DOS to conform to PI 387.2. 

PI387.2 has passed its ballots within IEEE, is being sent to 
the IEEE Standards Board for its approval, and has been sent 
to ISO for both registration as a Committee Draft and for 
ballot to progress to Draft International Standard. 

Copies of the current draft, PI 387.2/Draft 14a, April 1995, 
are available. 

New work in this area is planned to begin at the October 
POSIX meeting. The suggestions to date include a guide to 
best use of the current standard, a profile for DOS (and 
related) systems, version and patch/fix management, poli¬ 
cies in distributed management (especially related to what 
constitutes “success”) and associated recovery policies, file 
sharing and client management, hierarchical distribution, 
scheduling, and queueing and queue management. There is 
some leaning toward having each of these efforts supported 
in a separate POSIX project so that each can proceed atits 
own pace. No firm decision, however, has been made in that 
regard. 

In addition to the work being done with POSIX, there is a 
complementary effort underway within the System Manage¬ 
ment Working Group at X/Open. The X/Open effort is striv¬ 
ing to provide the necessary specifications to permit 
distributed interoperability. This is needed because PI 387.2 
does not specify the means by which distributed function is 
to occur. 
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Report on POSIX Conformance Testing 

Kathy Liburdy <kathy.liburdy@eng.clemson,edu> reports on 
the April 24-28,1995 meeting in Irvine, CA 

With 2003r still in ballot resolution, the newly formed Auto¬ 
mated Testing Study Group was the primary source of con¬ 
formance testing activity and entertainment at the April 
meeting. The agenda began with a presentation by John Hill 
on Formal Description Techniques (FDTS) and discussion 
generated by this presentation dominated the remainder of 
the meeting. 

Central to the discussion were the JTC1 directives which 
encourage the use of FDTs for new and existing standards in 
general. Soon after John’s description of the directives, 
members of the study group suggested that the group draft a 
recommendation to the SEC encouraging PASC to adopt a 
policy of following the JTC1 directives. The nearly instanta¬ 
neous polarization of positions regarding this idea suggests 
that unfounded beliefs may be contributing, at least in part, 
to the perception of FDTS. In fairness to the image of FDTS, 
the following two statements are presented as myths: 

• Formal Descriptions are Language Independent Specifica¬ 
tions. Not always. Formal descriptions can be either pro¬ 
gramming language dependent (e.g., ADL is heavily biased 
toward the C language) or programming language indepen¬ 
dent (e.g., Z is not based on any programming language). 

• Formal Descriptions guarantee automated testing. They do 
not. While some formal description languages directly sup¬ 
port automated testing (e.g., CATS), others were created 
with different goals influencing their design (e.g., Z). The 
impact on test development from formal descriptions 
which are not directly translatable into executable tests is 
not clear. 

Closer to reality is the following statement regarding FDTs: 
FDTS encompass a rich and diverse collection of formal 
specification languages. In the same way that programming 
languages may be characterized by different features and 
limitations, so may formal specification languages. 

Formal specification languages share in common a mathe¬ 
matical basis which permits precise, unambiguous descrip¬ 
tions. A precise, unambiguous description is necessary (but 
not sufficient) for automated translation of descriptions into 
tests. 

While the basic relation of automated testing to FDTk is 
clear, the relation of FDTs to standards development in gen¬ 
eral is not. The multitudes of domains in the software stan¬ 
dards arena coupled with the diversity of characteristics of 
formal specifications languages presents an unenviable bur¬ 
den for anyone (or any group) attempting to justify a sweep¬ 


ing statement such as “Use FDTS for all standards.” 
Pragmatic issues such as the impact on participation by vol¬ 
unteers to develop the standards and the understandability 
of the final product should be thoroughly studied in addition 
to the acclaimed benefits of FDT^. 

Fortunately, this task is far removed from the charter of the 
Automated Testing Study Group. If enough interest in 
applying FDTs to standards development is generated by 
this study group and elsewhere, a new study group may be 
formed to study these issues. 

The Automated Testing Study Group will reconvene in 
Nashua, NH to further discuss issues related to automated 
testing. The real issue at hand may not be the technical mer¬ 
its and theoretical issues of FDTs, but rather: do the current 
rules and politics of PASC allow a test methods standard to 
be developed using a formal specification language which 
supports automated testing? If the answer is no, then the 
study group should consider ways to open the door for test¬ 
ing standards which support automated testing. If the 
answer is yes, the study group should probably dissolve and 
send its members on their way to do real work. 

Meanwhile, a stalled effort in the development of the 
2003,5 standard and a funded effort to develop a test suite 
for POSIX.5 has created a reversal of previous PASC 
approaches to conformance testing: the work on the test 
suite implementation is getting ahead of the standardization 
effort! Testing standards in PASC have traditionally pre¬ 
ceded the implementation of the test suite implementation. 
The (unplanned) approach by the POSIX.5 Test Suite/2003.5 
Standard effort is more along the lines of conventional stan¬ 
dards development: standardize based upon existing prac¬ 
tice (if there is sufficient reason to standardize at all). 

The value of a test methods standard remains questionable. 
In keeping with the model established by base standards, the 
standardization of “testing” interfaces might be more appro¬ 
priate than attempting to standardize a restatement of the 
base standard. This observation is based on experience 
gained during the development of the test suite for POSIX.5 
in cases where required behavior is stated, but interfaces to 
confirm the behavior are missing. 

Another possibility which is emerging from the POSIX.5 test 
suite development is that of submitting the testing strategy 
used in the test suite implementation for consideration as a 
Recommended Practice. This approach has some appeal in 
that the open review provided by the balloting process may 
enhance the corresponding test suite. Regardless of the out¬ 
come, this effort has succeeded in raising some important 
questions about conformance testing in open systems stan¬ 
dards. Hopefully, the POSIX.5 test suite experience will pro¬ 
vide insights into these issues. The test suite is scheduled for 
completion in October 1995. 
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Report on POSIX.4 - Programming 
For The Real World 

by Nick Stoughton 
<nick@pert.co.uk> 

[As it turns out, this is a book review - Ed.] 

Those of you who have followed the Standards Activity col¬ 
umn in ;login: over the years will doubtless recognise the 
name Bill O. Gallmeister, one time vice chair of the 
POSIX.4 working group, and long time snitch on realtime 
work. 

Bill’s practice in writing snitch reports has clearly paid off 
in his new book, POSIX.4 - Programming For The Real 
World , published by O’Reilly. At some 550 pages, this is no 
bedtime story, but the style throughout the early chapters 
makes easy reading. The trouble with reading a book writ¬ 
ten by someone you know well is that you can almost hear 
him saying some of the phrases and explanations. Bill’s 
character and personality have tainted those early chapters, 
but as an easy going Californian BWG (Bearded White 
Guy), that taint is in no way offputting. 

The book consists of two principle sections: the first is a 
simple introduction to writing portable applications using 
the POSIX.lb interfaces, while the second half is a reference 
section to those interfaces, presented in nice familiar man 
page format. This format is just how I like it; after I’m done 
reading the introductory stuff, all I want is a good reference 
book. I rarely if ever go back to look at primers once I’ve 
read them. This book is laid out in a style that means I am 
likely to use it every working day for the rest of my career 
(or for a long time at least). 

Bill points out that Realtime programming (that’s the offi¬ 
cial POSIX spelling of realtime) is not something strange 
that only missile guidance people need worry about. True, 
many of the interfaces are strange for programmers, who are 
used to building compilers and editors and such like tools. 
But to people building end-user applications, predictability 
is vital. 

In my personal experience, over the last 15 years or so I 
have gone from writing 100% system type applications, to a 
point now where about 50% of what I am designing and 
building is end-user applications. True, I haven’t had to 
write too many embedded realtime systems, but I do fall 
into the class of people that Bill classes as real world pro¬ 
grammers. As more and more computer systems are deliv¬ 
ered to end users, more and more of us are going to have to 
get used to real world things. The only trouble is, having set 
the scene so well in the preface and chapter 1, he only uses 
embedded, real realtime examples for the rest of the story! 


As I said, the book has two principle parts; a seven chapter 
“primer,” written in an easy-to-read style, complete with 
exercises (though some of these do appear a little labored), 
followed by a reference section. These sections are of 
approximately equal size, and this balance is excellent. The 
reference section should probably have covered all of 
POSIX.lb, including the old, perhaps familiar, POSIX. 1 
interfaces, but most of these are now so second nature to 
most of the intended audience, I can understand their omis¬ 
sion. 

The explanation of feature test macros is at best weak, at 
worst wrong. However, this is, in my mind, a minor gripe. 

Another minor problem is the choice of cover design: a 
series of pulleys and weights taken from an 19th Century 
English engraving entitled “Mechanics” suggests that the 
target audience is mechanical engineers. I think that’s unfor¬ 
tunate, because the real target audience is people like us - 
hackers. Most mechanical engineers I know would have dif¬ 
ficulty getting beyond the preface (OK, perhaps I’m being a 
little unfair), and faced with the pros and cons of using sig¬ 
nals as an interprocess communications mechanism would 
happily go back to their strings and pulleys, drawing car¬ 
toons of Bill instead of weights. Nevertheless, since I once 
studied engineering (I even have a real engineering text 
book with a remarkably similar cover design at home), and I 
am English, I think I can live with this one! 

The POSIX.lb standard incorporates all of POSIX. 1, and the 
entire standard is covered. However, the intended audience 
is, as I said, advanced C programmers. This means he does 
not cover straightforward interfaces like open, close, 
read, write, fork, and exec in anything more than a cur¬ 
sory fashion. In fact, they are even missing from the refer¬ 
ence section. The book concentrates on those new and 
unfamiliar realtime extensions that were made to POSIX. 1 to 
make POSIX.lb. 

The biggest complaint I can make about this book is the use 
throughout of the old term POSIX.4 - as Bill points out it 
has been renamed as POSIX.lb, but he finds that term too 
difficult to grasp. The standard I have on my bookshelf (in 
those rare moments when I’m not actually using it) is called 
POSIX.lb, formerly known as POSIX.4. The anachronistic 
use of the old title grates after a while, and I wish he had bit¬ 
ten the bullet along with all the rest of us in POSIX - we 
may not like the titles, but they are here to stay, and pretend¬ 
ing that the renumbering didn’t happen won’t make them go 
away! 

Over the years, plenty of people have bitched about what 
the POSIX.4 working group (and its still called that, even 
though their standard is part of POSIX. 1) did. Bill does not 
shy away from that, but does clearly point out that though 
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many of these interfaces are not traditional ones* that does 
not change their historical validity. The book makes almost 
no mention of the parallel activity of the POSIX.4 working 
group, the soon to be standard POSIX.lc (formerly POSIX.4a, 
Threads). This may be a problem in the long term, and I 
would encourage a future edition that does cover multi¬ 
threading when that standard is a reality. However, in the 
short term, what is covered, POSIX.lb, is covered excel¬ 
lently, and I would thoroughly recommend this work to any¬ 
one involved in portable application development that might 
need to consider any realtime aspect. 


Dilbert ® by Scott Adams 
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The Bookworm 

by Peter H. Salus 
<peter@uunet.uu,net> 

Travelling the Net 

The Internet and its appendages - BITNET, FidoNet, etc. - is a world-wide phe¬ 
nomenon. Yet, there are few user-oriented works in any language other than 
English. In Quebec at the beginning of May, I purchased two small books, the 
first such books in French Canada. 

Danny Sohier has done a fine job. The “basic functions” volume covers exactly 
that, containing a small historical introduction (remarkably free of the run-of- 
the-mill stupidities and with only one nit I could pick: IMP #2 was at the SRI, not 
at Stanford University. Sohier goes on to modes of access, social and legal impli¬ 
cations, and IP numbers and addressing. Next, Sohier discusses mail and news- 
groups (including mailing lists), telnet, and ftp. Throughout, he keeps a tone that 
I think will prove suitable to the uninitiated - necessary when you have produced 
the “premier livre sur Internet 6crit pour le Quebec” - without sacrificing reality 
(as so many of the books clogging the bookstores do). 

Sohier moves on to ftp, completing the four basic applications: mail, news, tel¬ 
net, and ftp. This chapter also contains a few paragraphs each on compression, 
archie, Gopher, and WWW. The volume ends with a list of Quebec Internet pro¬ 
viders, a sample of news groups (e.g., the Nordiques, the Canadiens, the Boston 
Bruins, AIDS, homebrew, and other topics), a short list of anonymous ftp servers 
and of telnet sites, a glossary, and a brief list of smileys. It’s a fine job. 

The “advanced functions” volume is really an introduction to Usenet, archie, 
Gopher, WWW, WAIS, and Veronica. Jughead is missing. Sohier has done a 
superb job, considering that this is the first volume in French Canada on these 
topics. In view of the fact that archie was created at McGill University in Mont¬ 
real and that Collyer and Spencer created C News at the University of Toronto, 
the Canadian contributions to these applications have been major. I found it 
especially impressive that Sohier gets the history right whenever he mentions it: 
e.g., Truscott, Ellis, and Bellovin in North Carolina in 1979. 

The appendices in this volume partially duplicate the ones in “basic functions,” 
but add a list of Gophers and one of Web sites. 

My one wish was that Sohier had said more about Mosaic, but perhaps that will 
go into a third volume. With the flood of new users onto the Matrix and with 
connectivity extending around the globe, we need more books like Sohier’s so 
that new users understand what they’re getting and how they can use what they 
get appropriately. 

I wish I could say equally nice things about Gilster’s new volume. It started out 
quite well, with an interesting chapter on how SLIP/PPP is different from shell 
access. But then it descended into connecting my PC to the Internet, to installing 
Trumpet Winsock (I don’t run Windows), and MacTCP (which I don’t have, 
either). While chapter 7 contains solid information on Telnet, it’s all stuff you 
already know. Geared for the gee-whiz PC/Mac user, this is a disappointment. 
Wiley has (appropriately) put Breughel’s “Tower of Babel” (1563) on the cover. 
They might have indicated that it is in the Kunsthistorisches Museum in Vienna. 


Books reviewed in this column: 

Danny J. Sohier, INTERNET: Le 
guide de survie de I’internaute 
(Fonctions de Base). Montreal: 
L’Editions Logiques, 1994. ISBN 2- 
89381-245-7. Pp. 181. CA$16.95. 

Danny J. Sohier, INTERNET: Le 
guide d’exploration de I’internaute 
(Fonctions Avancees). Montreal: 
L’Editions Logiques, 1995. ISBN 2- 
89381-253-8. Pp. 232. CA$18.95. 

Paul Gilster, The SLIP/PPP Connec¬ 
tion. New York: John Wiley & Sons, 
1995. ISBN 0-471-1712-9. Pp. 480. 
$24.95. 

Thomas K. Landauer, The Trouble 
with Computers. Cambridge, MA: 
MIT Press, 1995. ISBN 0-262-12186- 
7. Pp. 425. $27.50. 

Philip R. Zimmermann, The Official 
PGP User’s Guide. Cambridge, MA: 
MIT Press, 1995. ISBN 0-262-74017- 
6. Pp. 127. $14.95. 

Philip R. Zimmermann, PGP Source 
Code and Internals. Cambridge, 

MA: MIT Press, 1995. ISBN 0-262- 
24039-4. Pp. 907. $60. 

Daniel S. Janal, Online Marketing 
Handbook. New York: Van Nos¬ 
trand Reinhold, 1995. ISBN 0-442- 
02058-9. Pp. 370. $24.95. 

Linda Lamb & Jerry Peek, Using 
email effectively. Sebastopol, CA: 
O’Reilly & Associates, 1995. ISBN 
1-56592-103-8. Pp. 146. $14.95. 

Linda Mui, When You Can’t Find 
your UNIX System Administrator. 

Sebastopol, CA: O’Reilly & Associ¬ 
ates, 1995. ISBN 1-56592-104-6. Pp. 
139. $17.95. 

Brent B. Welch, Practical Program¬ 
ming in Tel and Tk. Upper Saddle 
River, NJ: Prentice Hall, 1995. ISBN 
0-13-182007-9. Pp. 428+3.5” dis¬ 
kette. $36. 
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Michael A. Friedman, Phuong Y. 
Tran, & Peter L. Goddard, Reliability 
of Software Intensive Systems. Park 
Ridge, NJ: Noyes Data Corporation, 
1995. ISBN 0-8155-1361-5. Pp. 404. 
$64. 

Dan Craigen, Susan Gerhart, & Ted 
Ralston, Industrial Applications of 
Formal Methods to Model, Design 
and Analyze Computer Systems. 
Park Ridge, NJ; Noyes Data Corpora¬ 
tion, 1995. ISBN 0-8155-1362-3. Pp. 
306. $54. 

W. Timothy Polk, et al., Anti-Virus 
Tools and Techniques for Com¬ 
puter Systems. Park Ridge, NJ: 
Noyes Data Corporation, 1995. ISBN 
0-8155-1364-X. Pp. 79. $24. 

Judith A. Clapp, et al., Software 
Quality Control, Error Analysis, 
and Testing. Park Ridge, NJ: Noyes 
Data Corporation, 1995. ISBN 0- 
8155-1363-1. Pp. 392. $54. 

Edward Feigenbaum, et al.. 
Advanced Software Applications 
in Japan. Park Ridge, NJ: Noyes 
Data Corporation, 1995. ISBN 0- 
8155-1360-7. $86. 

Emerson W. Pugh, Building IBM. 
Cambridge, MA: MIT Press, 1995. 
ISBN 0-262-16147-8. $29.95. 
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What's Wrong? 

Several decades ago Tom Landauer literally founded the field of human-com¬ 
puter interaction. Having left Bellcore for the University of Colorado, Land¬ 
auer has produced a genuinely socko volume on “usefulness, usability, and 
productivity.” He points out that despite the vast technical improvements in 
hardware and software over the past two decades, the productivity improve¬ 
ments in the service industries that were supposed to follow have not done so. 

Landauer’s main point - and it’s a good one - is that computers are too hard to 
use and do too little that is useful. My favorite section is one where he shows 
that the constant addition of features - putatively designed to make computers 
more marketable - merely increases cost and complexity while decreasing ease 
of use. 

If you’re reading this column, you should read this book. 

PGP 

MIT Press has produced a handy, reasonably-priced paperback user’s guide to 
Pretty Good Privacy by Phil Zimmermann. It also has a wonderfully polemic 
introduction by John Perry Barlow, who compares the US Government’s 
attempts at stopping PGP and forcing use of the Clipper Chip to “having a 
peeping tom install one’s blinds.” If you’ve read the articles Greg Rose has 
written on the grand jury and the way that Phil is harassed, you’ll realize that 
Phil needs all the support we can give him. (Incidentally, MIT Press has also 
brought out the source code and internals in a massive and handsome volume. I 
can only wonder: will buying this and mailing it to, say, Peter Collinson in 
Canterbury, Kent, make me guilty of “exporting munitions”?) 

Marketing 

As I generally detest the books that have arrived purporting to tell me how I 
can buy an automobile or advertise my CD-ROM of pictures of the back of Rob 
Pike’s head on the Internet, I was pleasantly surprised by Janal’s volume on 
online marketing. Janal goes through all the details from selecting a supplier 
through credit card ordering and such companies as Cybercash, Open Market, 
First Data, Digicash, etc. If you’re going to be advertising or vending products 
or services on the net, this is a good book to start with. I was especially 
impressed with Janal’s chapter on netiquette and his explanation and condem¬ 
nation of spamming. 

Knowledge is Power 

O’Reilly has launched yet another new series: “What you Need to Know.” The 
first two concern email and system administration. I found both of them read¬ 
able. Only time will tell whether they are useful. While the numbers of new 
users seem to be waxing, they are not waxing as fast as they once did. At the 
same time there are much more books on how I can tell whether my uncle is 
burning his toast or what the current temperature is in Nizhny-Novgorod. ORA 
seems to think these volumes are for the “new employee packet.” Maybe they 
are. At least they don’t make the reader feel like the possessor of an IQ lower 
than Forrest Gump’s. Each of those books with Simple or Dummy or Idiot in 
the title makes me feel like Sgt. Friday: I just want the facts. 

Each “What You Need to Know” volume contains anecdotal information in 
sidebars and sketches of various ORA staff. Most of the sketches are pretty 
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good. Perhaps ORA could give the artist up-front credit in 
the future. Her name is Leslie Evans. It is the very last thing 
on an unnumbered page at the end of each book, just before 
the ads. 

Tcl/Tk 

Brent Welch, who has been involved with many USENIX 
events over the years, has turned out a really splendid vol¬ 
ume on Tel [7.4] and Tk [4.01 programming. Even if you 
already have Ousterhout’s book, this one will prove useful. 
It also comes with a diskette of sample code (in tar format) 
tucked into the rear of the book. I thought that Brent’s dis¬ 
cussions of widgets and extensions were especially good. If 
you do X Window programming, you’re going to need this 
one. 

Technical Reports 

Every day, universities, research labs, government agencies, 
and commercial entities chum out thousands of pages of 
reports. Some of these (justifiably) never get out of the 
immediate location in which they are produced. Some oth¬ 
ers are of such value that they get copied and recopied and 
circulated inside the underground (John Lions’ V6 code and 
commentary are most likely the best example). A very few 
gain real publication. 

The five (expensive) volumes from Noyes Data fall into this 
last class. Reliability of Software Intensive Systems is photo¬ 
offset from two volumes that emanated from Griffiss Air 
Force Base / Rome Laboratoiy Air Force Systems Com¬ 
mand in 1991-1992. The first volume was done by Hughes 
Aircraft under contract. The material, unfortunately, is not 
easy to read, but it is definitely worthwhile. 

Industrial Applications. .. is reproduced from two volumes 
brought out by NIST in 1993. The first was on the formal 
methods of analysis, the second was made up of a dozen 
case studies. Some of these (INMOS, HP Medical Instru¬ 
ments, SACEM -A Railway Signalling System) were quite 
illuminating. 

Anti-Virus Tools. .. was also based on two NIST reports. I 
think that the area of viruses moves too fast for this sort of 
“permanent” publication to be useful. 

There are three technical reports that make up the volume 
on quality control, produced in 1992-1993 by The MITRE 
Corporation, Rome Lab, and NIST. While I admit to having 
had an interest in software quality and in version control 
since I first heard David Tilbrook expound on the topic, I 
found the varied typography produced by photoing hetero¬ 
geneous reports made this nearly unreadable. 


The volume on software applications in Japan is comprised 
of four reports done through JTEC at Loyola in Maryland, 
between 1990 and 1993. They have historical value, but are 
of little importance where either competitiveness in high- 
tech areas or technological development are concerned. 
Again, the nature of the typography is quite off-putting. 

Big Blue's Story 

Everyone knows that I’m interested in technological history. 
Emerson Pugh has written all or part of three previous 
works on IBM. Building IBM is a cross between business 
history and technology. As an insider, Pugh had access to all 
of IBM’s archives. The result is a book that goes from Hol¬ 
lerith and his punched cards in 1890 to the underlying 
causes of Big Blue’s decline in the 1990s. A really splendid 
piece of work. 

Triple Play 

Just a brief note: Prentice Hall has brought out third editions 
of Stallings’ ISDN and Broadband ISDN. . . (1st ed., 1989; 
2nd ed., 1992) and of Doug Comer’s Internetworking with 
TCP/IP, vol 1 (1st ed., 1988; 2nd ed., 1991). The new Stall¬ 
ings has a lot of detail on ATP and frame relay; Comer now 
has details on IPv6 [aka IPng]. 
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ANNOUNCEMENTS & CALLS 


9th Systems 
Administration 
Conference (LISA ‘95) 

September 18-22,1995 
Monterey, California 

Mark your calendars now!! If you are a novice or experi¬ 
enced system administrator, you will want to attend LISA 
‘95, the 9th Systems Administration Conference co-spon¬ 
sored by the USENIX and SAGE. This is the original confer¬ 
ence dedicated entirely to systems administration issues, 
given for and by system administrators. Here is the prelimi¬ 
nary LISA ‘95 conference program: 

Tutorial Program: 

Sunday - Tuesday, September 17-19 

Sunday, September 17 

Joining the Internet Safely Using UNIX and Firewalls 
Introduction to UNIX System Administration 

Monday, September 18 

New Topics in System Administration 

UNIX Security 

Sendmail Inside and Out 

Introduction to System Performance Tuning 

Administering the Domain Name System 

GUI Programming in Perl 

An Introduction to HTML 

IP Network Administration 

Breaking the Communication Barrier 

New Manager’s Survival Guide 

Tuesday, September 19 

Topics in System Administration 

Joining the Internet Safely Using UNIX and Firewalls 

Beginning Perl Programming 

Solaris System Administration 

UNIX Security: Threats and Solutions 

What’s New in Sendmail 8.7 

How to Plan Internet Security and Firewalls 

Legal Issues for System Administrators 

World Wide Web Programming with CGI 

Web Server Administration 


Technical Sessions 

Wednesday - Friday, September 20-22 

Wednesday, September 20, 1995 

Keynote Address: Hardware, Wetware, and Software 
John Mashey, Silicon Graphics 

lbnamed (A Load Balancing Name Server in Perl) 

Roland J. Schemers, SunSoft 

LPRng - An Enhanced Printer Spooler System 
Patrick Powell , San Diego State University 

Finding a Needle in a Virtual Haystack: Whois++ 
and the Whois++ Client Library 
Jeff Allen, Harvey Mudd College 

Panel Discussion: Management of Mission-critical 
Applications on Large Farms of UNIX Workstations. 
Panelists: Aaron Goldberg and Yuval Lirov, Lehman; Dan 
Geer, OpenVision Technologies 

Capital Markets Trading Floors, Current Practice 
Alan Kadin, Fidelity Investments; Sam Lipson, Morgan 
Stanley Japan Ltd. 

Morgan Stanley’s Aurora System: Designing a Next 
Generation Global Production UNIX Environment 
Xev Gittler and W. Phillip Moore, Morgan Stanley 

How to Upgrade 1500 Workstations on Saturday, 
and Still Have Time to Mow the Yard on Sunday 

M. Shaddock, M. Mitchell, and H. Harrison, SAS Institute 

Invited Talk: Spamming, Spoofing and Spying on Your 
Personal Global System 

N. L. Schryer, AT&T Bell Laboratories 

Security Administration in an 
Open Networking Environment 
Karen Casella , Sun Microsystems, Inc. 

Multi-platform Interrogation and Reporting with Rscan 
Nathaniel Sammons, Colorado State University 

Exu -A System for Secure Delegation 

of Authority on an Insecure Network 

Karl Ramm and Michael Grubb, Duke University 

Panel Discussion: Commercial Models of UNIX Support 
Panelists: Jennifer Lawton, Net Daemons Associates; Steve 
Simmons, Inland Sea; Yun S.Choi, Pilot Networking Ser¬ 
vices, Inc. 
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Thursday, September 21, 1995 

Invited Talk: Electronic Commerce: What It Means to You 
Dan Geer, OpenVision Technologies 

Administering Very High Volume Internet Services 
Dan Mosedale, William Foss, and Rob McCool, Netscape 
Communications 

Bringing the MBONE Home: Experiences with Internal Use 
of Multicast-Based Conferencing Tools 
Arch Mott, Cisco Systems, Inc. 

LACHESIS: A Tool for Benchmarking 
Internet Service Providers. 

Jeff Sedayao, Intel Corporation 

Works-in-Progress Session 

From Something to Nothing (and back) 

Gretchen Phillips, State University of New York at Buffalo 

Metrics for Management 
Christine Hogan , Synopsys, Inc. 

SQL-2-HTML: Automatic Generation of 
HTML Database Schemas. 

Jon Finke, Rensselaer Polytechnic Institute 

Highlights from the 5th USENIX UNIX Security Symposium 

Decentralising Distributed System Administration 
Christine Hogan, Synopsys, Inc.; Aoife Cox , Lockheed- 
Martin; Tim Hunter, Synopsys, Inc. 

SPM: System for Password Management 
Michael A. Cooper ; University of Southern California 

AGUS: An Automatic Multi-Platform 
Account Generation System 

Paul Riddle and Paul Danckaert, University of Maryland, 
Baltimore County; Matt Metaferia , MCI Telecommunica¬ 
tions 

Invited Talk: From ARPANET to Internet 
Peter H. Salus, Author and Enthusiast 


Friday, September 22, 1995 

Invited Talk: The Truth About ATM 
Berry Kercheval, Xerox PARC 

OpenDist - Incremental Software Distribution 
Peter W. Osel and Wilfried Gaensheimer, Seimens AG 

filetsf: A File Transfer System Based on lpr/lpd 
John Sellens, University of Waterloo 

Patch Control Mechanism for Large Scale Software 
Atsushi Futakata, Central Research Institute of Electric 
Power Industry 

Panel Discussion: Integration of PCs 

in a UNIX Computing Environment 

Hal Pomeranz, The NetMarket Company; Rob Reynolds, 

Hewlett-Packard Laboratories; Marshal Wilensky, Novell 

From Twisting Country Lanes to 
MultiLane Ethernet SuperHighways 
Stuart McRobert, Imperial College 

From thinnet to 10 baseT, from 
Sys Admin to Network Manager 
Arnold de Leon, Synopsys, Inc. 

Tracking Hardware Configurations in a 
Heterogeneous Network with syslogd 
Rex Walters, IBM Microelectronics 

Panel Discussion: Computing in the Year 2000 
Moderator: Rob Kolstad, BSDI ; Panelists to be announced 

To register, call the USENIX conference office at 
714-588-8649 or send email to <conference@usenix.org>. 
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October 29-November 1, 1996 
Seattle, Washington, USA 



2nd USENIX Symposium on 


operating systems design and implementation (OSDI '96) 


Pre-Announcement and Call for Papers 



Sponsored by the USENIX Association 
Co-sponsored (pending) by ACM SIGOPS and 
IEEE TCOS 

After a successful first OSDI symposium, the next OSDI 
will continue to focus on practical issues related to modern 
operating systems. OSDI brings together professionals from 
academic and industrial backgrounds, and has become the 
perfect forum for issues concerning the design and imple¬ 
mentation of operating systems for modern computing plat¬ 
forms such as workstations, parallel architectures, mobile 
computers, and high speed networks. 

The OSDI symposium emphasizes both innovative 
research and quantified experience in operating systems. We 
seek papers describing original work concerning the design, 
implementation, and use of modern operating systems. 
Besides mature work, we encourage submissions describing 
exceptionally promising, well-grounded speculative work, 
or enlightening negative results. Topics of interest include, 
but are not limited to: 

OS structure and organization 
OS kernel internals, servers and applications 
Distributed and mobile computing 
Multiprocessor and parallel systems 
Communications 

Storage Management and I/O systems 
Security in distributed systems 
Scalability and availability 
Heterogeneous systems 
Performance and optimizations 
Language support for OS 
OS interaction with HW architecture 


OS support for embedded systems 
OS support for real time and multimedia 
Interaction of OS and applications 

Program Committee 

Karin Petersen, Xerox PARC (co-chair) 

Willy Zwaenepoel, Rice University (co-chair) 

Peter Chen, University of Michigan 

Richard Draves, Microsoft Research 

Carla Ellis, Duke University 

Ed Felten, Princeton University 

Jim Gray, Microsoft Bay Area Laboratory 

Kevin Jeffay, University of North Carolina 

David Johnson, Carnegie Mellon University 

Jay Lepreau, University of Utah 

Jeff Mogul, DECWRL 

Marc Shapiro, INRIA 

John Wilkes, Hewlett-Packard Labs 

John Zahorjan, University of Washington 

Important Dates 

Full papers due: May 7, 1996 
Notification to authors: July 30, 1996 
Revised papers due for shepherding; August 19, 1996 
Camera-ready full papers due: September 16, 1996 

Submission Process 

Authors are required to submit full papers by May 7, 1996. 
Submitted papers should be no longer than 14 pages, spaced 
no closer than standard 10 point font on 12 point baseline, 
single- or double-column format. Longer submissions will 
be discarded without review. Very similar papers must not 
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have been published or submitted for publication else¬ 
where. All submissions will be held in the highest confiden¬ 
tiality prior to publication. Papers accompanied by so-called 
“non-disclosure agreement” forms are not acceptable and 
will be returned unread. 

The papers will be judged on significance, originality, 
clarity, relevance, and correctness. The committee will favor 
papers with reproducible results, especially those supplying 
detailed data and explanations, or offering to make data sets 
or source code available. 

Accepted papers will be shepherded through an editorial 
review process by a member of the program committee. 

Authors of accepted papers will be expected to provide 
an HTML page containing the abstract and links to 
their paper, slides, and software, if available. This will be 
collected after the event for inclusion in an electronic 
version of the symposium (for an example, see 
http:/huwiu. cs. Utah. edul- lepreau/osdi94/). 

Where to submit 

Submission of all papers must be made in both paper and 
electronic form. Fifteen (15) paper copies (double sided if 
possible) of the paper must be sent to: 

Willy Zwaenepoel 

Department of Computer Science, 

Rice University 

6100 S. Main St. 

Houston, TX 77005, USA 

and one electronic copy in Postscript (not ASCII) must be 
submitted by electronic mail to: osdi-papers@cs.rice.edu 

For administrative reasons (not blind reviewing), every 
submission (in both its paper and electronic form) should 
include one additional page containing: (i) paper title and 
authors, indicating any who are full time students, and (ii) 
for the author who will act as the contact to the program 
committee, his or her name, paper mail address, daytime 
and evening phone numbers, email address and fax number, 
if available. The cover sheet mailed with the electronic 
paper submission should be in ASCII to facilitate accurate 
on-line bookkeeping, and should be included in the same 
electronic mail message as the PostScript file containing the 
paper. 

All submissions will be acknowledged by May 21, 1996. 

If your submission is not acknowledged by this date, please 
contact the program chairs promptly at osdi@cs.rice.edu. 


Symposium Overview 

The symposium will consist of one day of tutorials, followed 
by 2.5 days of single-track technical sessions with presenta¬ 
tions of the refereed papers, and a halfday workshop on a 
topic yet to be determined. One of the technical sessions 
will be dedicated to work-in-progress presentations and will 
be described in later announcements. The refereed papers 
will be published in the Proceedings, provided free to tech¬ 
nical session attendees and available for purchase from 
USENIX. The Proceedings may also be distributed to ACM 
SIGOPS members. Papers of particular merit will be 
selected to receive an award and will be published in the 
IEEETCOS Bulletin. 

Registration Materials 

Materials containing all details of the technical and tutorial 
programs, registration fees and forms, and hotel information 
will be mailed in August 1996. If you wish to receive the 
registration materials, please contact: 

USENIX Conference Office 
22672 Lambert St., Suite 613 
Lake Forest, CA USA 92630 
Phone: 714 588 8649 
Fax: 714 588 9706 
Email: conference@usenix.org 
WWW URL: http://wiow.usenix.org. 
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A UNIQUE OFFER 
ON THE BEST IN UNIX 
FOR USENIX MEMBERS 


□ TIIE INTERNET 
GUIDE FOR NEW 
USERS 

D. Dern 

hardcover, 016510-6, $40.00, 
MEMBER PRICE $32.00 
paperback, 016511-4, $27.95, 
MEMBER PRICE $22.36 

□ INTERNET FOR 
EVERYONE 

R. Wiggins 

hardcover, 067018-8, $29.95, 
MEMBER PRICE $23.96 
paperback, 067019-6, $45.00, 
MEMBER PRICE $36.00 

□ TIIE ESSENTIAL 
INTERNET 

INFORMATION GUIDE 

J. Manger 

707905-1, paperback, $27.95, 
MEMBER PRICE $22.36 


% ^SjT 

DISCOUNT FROM 
McGRAW-IIILL 

□ THE INFORMATION 
BROKERS 
HANDBOOK, 

Second Edition 

S. Rugge 

911878-x, paperback, $34.95, 
MEMBER PRICE $27.96 
Available December 1994 

□ SAA AND UNIX: IBM’s 
Open System Strategy 
M. Killen 

034607-0, $40.00, 

MEMBER PRICE $32.00 

□ A STUDENT S GUIDE 
TO UNIX 

H. Hahn 

025511-3, paperback, $28.00, 
MEMBER PRICE $22.40 


□ UNIX DEVELOPER’S 
TOOL KIT 

K. Leininger 

911836-4, $65.00, 

MEMBER PRICE $52.00 

□ UNIX SECURITY: 

A Practical Tutorial 

N. Arnold 

002560-6, $24.95, 

MEMBER PRICE $19.96 

□ THE UNIX AUDIT: 
Using UNIX to Audit 
UNIX 

M. Grot-tola 

025127-4, $32.95, 

MEMBER PRICE $26.36 

□ UNIX: A Database 
Approach 

S. Das 

015745-6, $29.95, 

MEMBER PRICE $23.96 
Available November 1994 


I am a member of USENIX Association. Please 
send me the books I have indicated at the 
member special rate. I have added $3.00 postage 
and handling for the first book ordered, $ 1.00 
for each additional book, plus my local sales tax. 

Check or money order is enclosed— 
payable to McGraw-Hill, Inc. 

Charge my □ Visa □ Mastercard 

□ Discover □ Amex 

Account#_ 

Expiration Date_ 

Signature.___ 


USENIX Membership # 


Bill & Ship To: 


City. State, Zip_ 

Daytime Phone #_ 


Send or Fax Orders to: 

W 1 McGraw-Hill, Inc. 

SuiwJ Attn: Rosa Perez 

I SIS | 11 West 19th Street—4th Floor 
■ mII New York, New York 10011 
Fax: 212-337-4092 


If I am not completely satisfied, I will return the book(s) within 15 days for a full refund or credit. Satisfaction unconditionally 
guaranteed. Prices subject to change without noties. We can only accept orders within the continental USA. 
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Commemorating 25 years of UNIX 


This year UNIX marks its 25th anniversary. We think its something 
to celebrate. After all, we owe our livelihoods to UNIX. Over the 
years it’s given us plenty to explore, learn, teach, and talk about. 
It’s enabled us to do good work—work that’s filled with adven¬ 
ture, fun, and creative challenge. We couldn’t ask for much more 
than that. Except, of course, for a little cake and ice cream. 


You might like to celebrate with these new titles from O’Reilly: 
Managing Internet Information Services , The Mosaic Handbook 
(with software for three platforms, including Microsoft Windows, 
X, and the Macintosh), X User’s Tools, Motif Tools , PGP; Pretty 
Good Privacy , and Multi-Platform Code Management. Call or 
write to us at the numbers below for details. Mention code ALOG. 


O’REILLY & ASSOCIATES, INC. 

103A Morris Street, Sebastopol, CA 95472 FAX: 707-829-0104 
Credit card orders: 1-800-889-8969 Weekdays 6AM-6PM PST 
Online orders: order@ora.com 

For inquiries or to request a copy of our catalog: 1-800-998-9938 

















Computer Publications from John Wiley & Sons, Inc. 



USENIX members receive 
a 15% discount 


The Internet Navigator, 2ed 
Paul Gilster 

1-05260-4 $24.95 member price: $21.20 

# of copies: _ 

Advanced Topics in UNIX 
Ronald Leach 

1-03663-3 $24.95 member price: $21.20 

# of copies: _ 

Introduction to Client Server Systems 
Paul Renaud 

1-57774-X $34.95 member price: $29.70 

# of copies: - 

Portable UNIX 
Douglas Topham 

1-57926-2 $14.95 member price: $12.71 

# of copies: - 

UNIX, Self-Teaching Guide 
George Leach 

1-57924-6 $19.95 member price: $16.95 

# of copies: _ 

Object Oriented Programming with Turbo C++ 
Keith Weiskamp 

1-52466-2 $24.95 member price: $21.20 

# of copies: _ 

Obfuscated C and Other Mysteries 
Don Libes 

1-57805-3 $39.95 member price: $33.96 

# of copies: - 


l I Payment enclosed, plus sales tax 
I | VISA n Mastercard 
l—i American Express 

Card No._ 

Name_ 

Firm _ 

Address_ 

City/S late/Zip_ 

S ignaturo_ 

(order invalid unless signed 


Finding It On the Internet 
Paul Gilster 

1-03857-1 $19.95 member price $16.95 

# of copies: _ 

Internationalization: Developing Software for 
Global Markets 1-07661-9 (pub. date: 1/95) 
Tuoc Luong $29.95 member price: $25.45 

# of copies: _ 

Adventures in UNIX Network Applications 

Programming 

Bill Rieken 

1-52858-7 $39.95 member price: $33.96 

# of copies: _ 

UNIX Shell Programming, 3e 
Lowell Jay Arthur 

1-59941-7 $29.95 member price: $25.45 

# of copies: _ 

The UNIX Command Reference Guide 
Kaare Christian 

1-85580-4 $32.95 member price: $28.01 

# of copies: _ 

Berkeley UNIX: A Simple & Comprehensive 
Guide 

James Wilson 

1-61582-X $40.95 member price: $34.80 

# of copies: _ 
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USENIX members receive a 15% discount 
on the following MIT Press publications: 


TECHNOLOGY 2001 

The Future of Computing and Communications 

edited by Derek Leeboert 

Researchers, executives, and strategic planners from inside the 
companies and laboratories that have shaped today's information age 
forecast the merging technologies that could well define the computing 
and communications environment that lies ahead. 

392 pp $ 14 95 paperback LEEEP 

THE DIGITAL WORD 

Text-Based Computing in the Humanities 

edited by George P. Landow and Paul Delany 

This book explores the larger realm of the knowledge infrastructure 
where texts are received, reconstructed, and sent over global networks. 
Technical Communication and Information Systems series 384 pp $39 95 
hardcover LANDH 

SOCIOMEDIA 

Multimedia, Hypermedia, and the Social 
Construction or Knowledge 

edited by Edward Barrett 

Scciomedia continues the assessment of hypertext and hypermedia 
systems begun in 7 ext. Context, and Hypertext and The Society of 
Text. It examines the use of integrated multimedia to support social or 
collaborative research, learning, and instruction in the university, one of 
the best environments for developing and analyzing the effects of 
computing technologies on our understanding of complex sets of 
information, 

Technical Communications and Information Series 360 pp $50 00 hardcover 
BARRH 


GLOBAL NETWORKS 

Computers and International 
Communication 

edited by Linda M Harasim 

Global Networks lakes up the host of issues raised 
by the new networking technology that now links 
individuals, groups, and organizations in different 
countries and on different continents. The twenty- 
one contributions focus on the implementation, 
application, and impact of computer-mediated 
communication in a global context. 

340 pp. $29 95 hardcover HARNH 

THE NETWORK NATION 

Human Communication via Computer 
Revised Edition 

Starr Roxanne Hiltz and Murray Turoff 
"The Network Nation... contained a fascinating 
vision. .. .It is a place where thoughts are 
exchanged easily and democratically and intellect 
affords one more personal power than a pleasing 
appearance does. Minorities and women 
compete on equal terms with white males, and the 
elderly and handicapped are released from the 
confines of their infirmities to skim the electronic 
terrain as swiftly as anyone else. 1 ' — Teresa 
Carpenter, Village Voice 
580 pp $24.95 paperback HILWP 

THE EVOLUTION OF C++ 

Language Design in the Marketplace of 
Ideas 

edited by Jim Waldo 

This collection of articles traces the history of C++, 
from its infancy in the Santa Fe workshop, to its 
proliferation todoy as the most popular ob|ect- 
oriented language for microcomputers Waldo 
notes in his postscript that in the process of 
evolving, the language has lost a clearly articu¬ 
lated, generally accepted design center, with no 
common agreement about what it should or should 
not do in the future. 

279 pp $24 95 paperback WALEP 


CONNECTIONS 

New Ways of Working in the Networked 
Organization 

Lee Sproull and Sara Kiesler 

Sproull arid Kiesler raise crucial questions about our technical and 
particularly our human strategies as a producing society." 

— Howard Webber, Sloan A Management Review 

228 pp $21 95 paperback SPRCP 

TECHNOBABBLE 

John A. Barry 

"A serious study of the language of the new technocracy." 

— William Safire, The New York Times Magazine 

288 pp $ 1 2 50 paperback BARCP 


Please send me these titles 

__ Payment enclosed Purchase Order Attached 
Card # exp. 


Charge to my: □ Master Card VISA 


Signature 


Total for book(s) 

Postage for North American addresses 
Canadian customers add 7% GST 
Total for book(s) & postage 


Make checks payable 
and send order to: 

THE MIT PRESS 

55 Hayward Street, Cambridge, AAA 

02142-1399 USA 

To order by phone, call 

(617)625-8569 

or (800) 356-0343. E-mail order 

# mitpress-orders@mit.edu. The 

operator will need this code: UNIX1. 


Name 

Address 
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Prentice Hall PTR is pleased to recommend 
the following titles to USENIX members... 



.UNIX System Administration Handbook, Second Edition, 

Evi Nemeth/Garth Snyder, 0-13-151051-7 
(15105-0) List: $48.00 Members: $40.80 


Object-Oriented Modeling and Design, 

James Rumba ugh, 0-13-629841-9 

(62984-0) List: $54.00 Members: $45.90 

Zen and the Art of the Internet, Third Edition, 

Brendan Kehoe, 0-13-121492-6 

(12149-1) List: $23.95 Members: $20.36 

The Magic Garden Explained, Bernard Goodheart/ 
James Cox, 0-13-098138-9 

(09813-7) List: $38.00 Members: $32.30 


Internetworking with TCPAP, Vol. Ill Client Server 
Programming and Applications for the AT&T TLI 
Version, Douglas E. Comer and David L. Stevens, 
0-13-474230-3 

(47423-9) List: $53.00 Members: $45.05 

The Internet Message: Closing the Book with Electronic 
Mail, Marshall T. Rose, 0-13-092941-7 
(09294-0) List: $50.00 Members: $42.50 

The Standard C Library, PJ Plauger, 0-13-131509-9 
(13150-8) List: $37.80 Members: $32.13 

.All About Administering the NIS+, Second Edition 

Rick Ramsey, 0-13-309576-2 

(30957-5) List: $42.00 Members: $35.70 

The Simple Book: An Introduction to Internet Management 

Marshall T. Rose, 0-13-177254-6 

(17725-3) List: $55.00 Members: $46.75 

.Networking Operations on UNIX SVR4, 

Mike Padavano, 0-13-613555-2 

(61355-4) List: $50.00 Members: $42.50 


Internetworking with TCP/IP, Vol. II Design, 
Implementation, and Internals, Douglas E. Comer/ 
David L. Stevens, 0-13-472242-6 
(47224-1) List: $61.33 Members: $52.13 

SCO Performance Tuning Handbook, Gina 
Miscovich/David Simons, 0-13-102690-9 
(10269-9) List: $42.00 Members: $35.70 

Object-Oriented Programming, Peter Coad/ 

Jill Nicola, 0-13-032616-X 

(03261-5) List: $48.00 Members: $40.80 

Internetworking with TCP/IP, Vol. Ill Client Server 
Programming and Applications for the BSD Socket 
Version, Douglas E. Comer and David L. Stevens, 
0-13-474222-2 

(47422-1) List: $53.00 Members: $45.05 


Solaris Porting Guide, SunSoft ISV Engineering 
0-13-030396-8 

(03039-5) List: $52.00 Members: $44.20 

Multiprocessor System Architectures, Ben Catanzaro 
0-13-089137-1 

(08913-6) List: $44.00 Members: $37.40 

The HP-UX System Administrator's "How To" Book 

Marty Poniatowski, 0-13-099821-4 

(09982-0) List: $32.00 Members: $27.20 

UNIX System V Performance Management, Edited by 
Phyllis Eve Bregman and Sally A. Browning 
0-13-016429-1 

(01642-8) List: $29.95 Members: $25.45 

SCO® UNIX® Operating System System Administrator's 
Guide, Santa Cruz Operation, 0-13-012568-7 
(01256-7) list: $39.00 Members: $33.15 


HERE'S HOW TO ORDER: 


CALL 

800 - 880-6818 


OR WRITE: 

CompuBooks 
Route 1, Box 271-D, 
Cedar Creek, TX 78612 


WE SHIP ANYWHERE! 


OR INTERNET: 

70007.1333@CompuServe.com 
(GO CBK on CompuServe) 


FOR MORE INFORMATION, OR QUANTITY ORDERS, PLEASE CALL 201-592-2657 
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ORDER FORM 


CONFERENCE & WORKSHOP PROCEEDINGS 



Q tv Pro cecditigs 

Member 

Price 

Non-Member• 
Price 

Stdbtotal 

Overseas 

Postage 

WINTER/SUMMER CONFERENCES 





New Orleans 

Winter '95 

30 

39 

$ 

20 

Boston 

Summer '94 

25 

33 

$ 

18 

San Francisco 

Winter '94 

30 

39 

$ 

20 

Cincinnati 

Summer '93 

25 

33 

S 

18 

San Diego 

Winter '93 

33 

40 

$ 

25 

San Antonio 

Summer '92 

23 

30 

$ 

14 

San Francisco 

Winter '92 

30 

39 

$ 

22 

Nashville 

Summer '91 

32 

38 

$ 

22 

Dallas 

Winter '91 

28 

34 

$ 

18 

Anaheim 

Summer '90 

22 

22 

$ 

15 

Washington, DC 

Winter '90 

25 

25 

$ 

15 

Baltimore 

Summer '89 

20 

20 

$ 

15 

San Diego 

Winter '89 

30 

30 

$ 

20 

San Francisco 

Summer '88 

29 

29 

$ 

20 

Dallas 

Winter '88 

26 

26 

$ 

15 

Phoenix 

Summer '87 

35 

35 

$ 

20 

Washington, DC 

Winter '87 

10 

10 

$ 

15 

Atlanta 

Summer '86 

37 

37 

$ 

20 

Denver 

Winter '86 

25 

25 

$ 

15 

Portland 

Summer '85 

45 

45 

s 

25 

Dallas 

Winter '85 

15 

15 

$ 

10 

Salt Lake City 

Summer '84 

29 

29 

$ 

20 

Washington, DC 

Winter '84 

25 

25 

$ 

15 

Toronto 

Summer '83 

32 

32 

s 

20 

San Diego 

Winter '83 

28 

28 

$ 

15 

LARGE INSTALLATION SYSTEMS ADMINISTRATION 





LISA VIII 

Sept. '94 

22 

29 

$ 

10 

LISA VII 

Nov. '93 

25 

33 

$ 

12 

LISA VI 

Oct. '92 

23 

30 

$ 

12 

LISA V 

Sept. '91 

20 

23 

$ 

11 

LISA IV 

Oct. '90 

15 

18 

$ 

8 

LISA III 

Sept. '89 

13 

13 

$ 

9 

LISA II 

Nov. '88 

8 

8 

$ 

5 

LISA I 

April ’87 

4 

4 

$ 

5 

C++ 





_ C++ Conference 

April '94 

24 

28 

$ 

20 

C++ Conference 

Aug. '92 

30 

39 

$ 

20 

_ C++ Conference 

April '91 

22 

26 

$ 

11 

_ C++ Conference 

April'90 

28 

28 

i 

18 

C++ Conference 

Oct. '88 

30 

30 

$ 

20 

_ C++ Workshop 

Nov. '87 

30 

30 

$ 

20 

SECURITY 






UNIX Security V 

June '95 

27 

35 

$ 

11 

UNIX Security IV 

Oct. '93 

15 

20 

$ 

9 

UNIX Security III 

Sept. '92 

30 

39 

$ 

11 

UNIX Security II 

Aug. '90 

13 

16 

$ 

8 

UNIX Security 

Aug. '88 

7 

7 

$ 

5 

MACH 





Mach Symposium III 

April '93 

30 

39 

$ 

18 

Mach Symposium 

Nov. ’91 

24 

28 

$ 

14 

Mach Workshop 

Oct. ’90 

17 

20 

$ 

9 


Total 


$_ 

$_ 

$_ 

$_ 

$. 

$_ 

$_ 

$. 

$. 

$. 

$. 

$. 

$. 

$. 

$. 

$. 
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Qty Proceedings 

Member 

Price 

Non-Member * 
Price 

Subtotal 

Overseas 

Postage 

Total 

DISTRIBUTED & MULTIPROCESSOR SYSTEMS (SEDMS) 






SEDMS IV 

Sept. '93 

24 

32 

$ 

14 

$ 

SEDMS III 

Mar. ‘92 

30 

36 

$ 

20 

$ 

SEDMS II 

Mar. '91 

30 

36 

$ 

20 

$ 

SEDMS 

Oct. ’89 

30 

30 

$ 

20 

$ 

MICROKERNELS & OTHER KERNEL 

ARCH. 






Microkernels & Other Kernel... II 

Sept. '93 

15 

20 

$ 

9 

$ 

Microkernels <St Other Kernel... I 

Apr. ’92 

30 

39 

$ 

20 

$ 

GRAPHICS 






Graphics Workshop V 

Nov. '89 

18 

18 

$ 

10 

$ 

Graphics IV 

Oct. '87 

10 

10 

$ 

10 

$ 

Graphics III 

Nov. '86 

10 

10 

$ 

5 

$ 

Graphics II 

Dec. 85 

7 

7 

$ 

5 

$ 

OTHER WORKSHOPS/SYMPOSIA 







Obiect-Oriented Technologies (COOTS) Tn ’95 

18 

24 

$ 

9 

$ 

Mobile Computing 

Apr. '95 

18 

24 

$ 

9 

$ 

OS Design and Implementation 

Nov. ’94 

20 

27 

$ 

11 

$ 

Very High Level Languages 

Oct. '94 

23 

30 

$ 

10 

$ 

High-Speed Networking 

Aug. '94 

15 

20 

$ 

9 

$ 

UNIX Applications Development 

April '94 

15 

20 

$ 

9 

$ 

Mobile Computing 

Aug. '93 

15 

20 

$ 

8 

$ 

File Systems 

May '92 

15 

20 

$ 

9 

$ 

UNIX Transaction Processing 

May '89 

12 

12 

$ 

8 

$ 

Software Management 

Apr. '89 

20 

20 

$ 

15 

$ 

UNIX & SuDercomDuters 

Sent. ’88 

20 

20 

$ 

10 

$ 

SAGE Short Topics System Administration Series 






Short Topics System Administration Series 







_ #1: Job Descriptions for System Administrators 

5 

7.50 

$ 

3.50 

$ 


Discounts are available for bulk orders. Please inquire. Total price of Proceedings 


Calif, residents add sales tax 
Total overseas postage 

**If you are paying member price, please include member's name and/or Total enclosed 

membership number_ 


PAYMENT OPTIONS* 

_ Check enclosed- payable to USENIX Association Account # __Exp.Date 

_ Charge my: _ VISA _ MC Signature - 

_ Purchase order enclosed 

* Outside the USA? Please make your payment in US currency by one of the following: 

-Check - issued by a local branch of a US Bank 

- Charge (VISA, MasterCard, or foreign equivalent) 

- International postal money order 

• If you are not a member and wish to receive our membership information packet, please check this box. I_I 

Shipping Information Ship to: 

Please allow 2-3 weeks for delivery. Overseas orders_ 

are shipped via air printed matter. Please mail or fax 
this order form with payment to: 


USENIX Association • 2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 • TEL 510-528-8649 • FAX 510-548-5738 
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Next Stop... 
San Francisco! 


/( 

rf I 



Plan now to be in San Francisco for UniForum '96 — 
a premier enterprise computing event showcasing 
Business Solutions across heterogeneous platforms 
to meet today's real world computing requirements. 

S UniForum ’96 

The Official Conference and Exposition for Open Computing Solutions. 

Conference: February 12-16, 1996 • Exposition: February 14-16, 1996 
Moscone Center • San Francisco, California 

Sponsored by UniForum, The International Association of Open Systems Professionals. 

Managed by The Interface Group, producer of COMDEX. 


©1995 The Interface Group • 300 First Avenue, Needham, MA 02194 2722 USA • (617) 449-6600 
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A Brand New Guide from UniForum 


I 



^UniForum 


About the Author: 

Michael Harrington is the 
systems administrator of the 
orthopaedic Biomechanics 
Laboratory at Beth Israel Hospital 
in Boston, Massachusetts. He is 
also a member of the UniForum 
Technical Steering Committee. 

He has more than eight years 
experience managing UNIX, 
Macintosh and PC networks. 

He has managed his own WWW 
server since 1993. 


Establishing a 
World-Wide Web Server 

A Systems Administrator’s Guide 



As Web sites proliferate throughout the world, and as users are demanding more 
functionality, the need for systems administrators to understand and manage World-Wide 
Web servers has never been greater. 

Establishing a World-Wide Web Server is a book that comes along at just the right 
time. There is no hotter application on the Internet than the World-Wide Web (WWW), 
and as it continues its explosive growth, it is up to systems administrators to understand 
and manage the demands of users. This Guide helps the administrator set up and 
administer a WWW server properly. The Guide is directed toward the novice system 
administrator and to those who take on the sys admin role in the course of their regular 
jobs. 

Establishing a World-Wide Web Server is written in a logical sequence that first 
introduces the reader to the place the WWW has in the world of the Internet. It then 
covers the technical issues including a clear description of HyperText Transfer Protocol 
(HTTP), with sections on several different HTTP servers. Subsequent chapters cover 
Uniform Resource Locators (URL), HyperText Mark-up Language (HTML) and a series 
of chapters on building and maintaining a WWW server. 

Establishing a World-Wide Web Server is thorough, easy-to-read, and completely 
up-to-date. 

All General Members of UniForum will receive a copy of 
Establishing a World-Wide Web Server as part of their 
membership benefits. 


Establishing a World-Wide Web Server Copies are available to all UniForum General and Trial Members 

Table Of Contents: at substantial discounts: 


■ Introduction: The WWW and the Internet quantity _ member price _ trial member price 


■ Technical Issues of the WWW 

■ URL 

■ HTML 

■ Forms 

■ Imagemaps 

■ Converters/Editors 

■ HTML+ 

■ Security Issues 

■ Maintaining a WWW Server 


I- 10 copies $10.00 $25.00 

II- 49 copies $8.00 $20.00 

50 copies or more $ 7.00 $17.00 

Plus shipping and handling 


Shipping & Handling Charges 

US/Canada/Mexico 

International 

If vour mechandise total is... 

Add... 

Add 

UP to $25.00 

$5.00 

$7.50 

$25.01 to 50.00 

7.00 

9.50 

$50 01 to 75.00 

9 00 

11.50 

$75.01 or more 

11.00 

13.50 


To order, please call UniForum today at 1 - 800 - 255 - 5620 , or ( 408 ) 986 - 
8840 Have your Visa, MasterCard, Discover or American Express Card 
ready for fastest order processing. Orders may be sent to UniForum. 
Please send checks or money orders (US dollars only; California 


Defining the Team Needed to Support the WWW 
Server 

Let’s Build a WWW Server 
The Future 

Glossary and Appendices 


residents please add applicable sales tax), to: 

UniForum 
WWW Server 

2901 Tasman Drive, Suite 205 
Santa Clara, CA 95054-1100 


ffillniForum 

The International Association of Open Systems Professionals 


9506201 



UniForum is a registered trademark of The UniForum Association. 







What is Open Systems and where can you find 
the information you need to keep up in today’s 
competitive open systems environment? 


The Advantages of Membership: 

Your annual membership is a resource treasure chest. Among the many valuable 
benefits you’ll receive are; 

■ UniForum Monthly: The Magazine for Open Systems Professionals 

■ UniNews - the authoritative voice of UniForum - now on-line 

■ The Open Systems Products Directory - comprehensive, accurate, indispensable 

■ Reduced fees at all UniForum conferences and seminars 

■ Technical and Standards publications: timely, reliable and useful 

■ Discounts on many outstanding industry publications 

■ Discounts on leading commercial hardware and software products 

■ Discounts on courses offered by leading training organizations 

■ Discounts on exclusive new shareware selections 

■ Services such as discounts on car rentals, travel and mail list rentals 

■ Eligibility to serve on UniForum committees and the Board of Directors 


Find out by joining UniForum: 

The International Association of Open Systems Professionals. 


UNIFORUM MEMBERSHIP APPLICATION FORM (pleaseprim) 

Name MR/MS 

Title _ 

Company 

Address 



General Membership** $125 

Includes UniForum Monthly magazine, UniNews electronic newsletter, Open Systems Products Directory, 
technical publications, recruitment advertising service, and discounts on: UniForum conference registration 
and shareware CD-ROMs, purchases of software and hardware, educational seminars and special classes, 
additional UniForum publications and other industry publications, computer books, CD-ROMs and training 
services. 

** Overseas postage: 

air $100 or surface $60 (no additional postage necessary for Canada, Mexico or Puerto Rico) $_ 

TOTAL AMOUNT ENCLOSED $_ 


Method of Payment: 

Select one: □ Check payable to UniForum * □ Money Order In US Dollars 


□ MasterCard 

□ Visa 

□ American Express 

Credit card number 


Expiration date 

Signature 


•Payments must be included in U.S. dollars. All checks must be drawn on a U.S. bank. Credit card orders can be accepted by telephone. 

••Overseas surface delivery takes up to six weeks. 

Send application and payment to: UniForum, 2901 Tasman Drive, Suite 205, Santa Clara, CA 95054-1100 
Tel: (408) 986-8840 (800)255-5620 Fax:(408)986-1645 

Prices subject Lo change without notice. Contact UniForum for discounts and shipping and handling charges on bulk orders. 

UniForum is a registered trademark of UniForom. UNIX is a registered trademark in the United Slates and other countries, 
licensed exclusively through X/Open Company Limited. Tl>« International As soda tier of Open Systems Professionals 



There’s Never 
Been a Better 
Time for an 
Outstanding 
Value 

As the unstoppable 
move to open systems 
gathers even more 
momentum you need a 
strong and 
independent 
association that can 
help you achieve your 
professional goals. 

An association that can 
magnify your voice, 
which can educate, 
inform and inspire. 
You need and deserve 
an association that 
provides value for your 
money. In short you 
need UniForum. 

With a value this good, 
the real question might 
be, “Can you afford to 
be without it?” 

Join today! 





LOCAL USER GROUPS 


The Association will support local 
user groups by doing a mailing to 
assist in the formation of a new 
group and publishing information 
on local groups in; login:. At least 
one member of the group must be a 
current member of the Association. 
Send additions and corrections to: 
<login@usenix. org>. 

California 

Fresno: 

The Central California UNIX Users 
Group has a WWW contact page to 
which members may post ques¬ 
tions or information. For connec¬ 
tion information: 

• Steve Mitchell 
209 278-5675 

<http:/l warpig. cati. csufresno.edu! 
ccuug! ccuug.html> 

Orange County: 

Meets the 2nd Monday of each 
month. 

• UNIX Users Association of 
Southern California 
Dave Close 

714 434-7359 

<dhclose@alumni.caltech.edu> 

New Horizons Computer 

Learning Center 

1231 E. Dyer Rd., Suite 140 

Santa Ana, CA 92705 

714 438-9440 

Colorado 

Boulder: 

Meets monthly at different sites; for 
membership information and meet¬ 
ing schedule, send email to 
<fruug-info@fruug.org >. 

• Front Range UNIX Users Group 
Lone Eagle Systems Inc. 

636 Arapahoe #10 
Boulder, CO 80302 
Steve Gaede 
303 444-9114 
<gaede@fruug.org> 

<http: Hwww.fruug.org! ~fruug> 


Washington, D.C. 

Meets 2nd Tuesday of each month. 

• Washington Area UNIX Users 
Group 

10440 Shaker Drive, Suite 103 
Columbia, MD 21046 
Alan Fedder 
301 621-5500 
<afedder@mcsp. com > 

Florida 

Coral Springs: 

• S. Shaw McQuinn 
305 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 

Melbourne: 

Meets the 3rd Monday of every 
month. 

• Space Coast UNIX Users Group 
Steve Lindsey 

407 242-4766 
<lindsey@vnet.ibm.com> 

Orlando: 

Meets the 3rd Thursday of each 
month. 

• Central Florida UNIX Users Group 
Mikel Manitius 

407 3 84-4644 

<mikel. manitius@east . sun. com> 

Western: 

Meets 1st Thursday of each month. 

• Florida West Coast UNIX Users 
Group 

Mike Delucia 
813 882-0770 
< pfl @cftnet. com > 


Georgia 

Atlanta: 

Meets on the 1st Monday of each 
month in White Hall, Emory Univer¬ 
sity. 

• Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 
Mark Landry 404 365-8108 


Kansas or Missouri 

Meets on 2nd Tuesday of each month. 

• Kansas City UNIX Users Group 
(KCUUG) 

P.O. Box 412622 
Kansas City, MO 64141 
816 891-1093 
<richj@northcs. cps.com> 

Michigan 

Detroit/Ann Arbor: 

Meets on the 2nd Thursday of each 
month in Ann Arbor. 

• Southeastern Michigan Sun Local Users 
Group and Nameless UNIX Users Group 
Steve Simmons’ office: 313 769-4086 
home: 313 426-8981 
<scs@lokkur.dexter.mi. us> 

Minnesota 

Minneapolis/St. Paul: 

Meets the 1 st Wednesday of each month. 

• UNIX Users of Minnesota 
17130 Jordan Court 
Lakeville, MN 55044 
Robert A. Monio 

612 220-2427 
<pnessutt@dmskq.mn.org> 

Missouri 

St. Louis: 

• St. Louis UNIX Users Group 

P.O. Box 2182 St. Louis, MO 63158 
Terry Linhardt 
314 772-4762 
<uunet!jga ltstl!terry> 

Nebraska 

Omaha: 

Meets monthly. 

• /usr/group/nebraska 
P.O. Box 31012 
Omaha, NE 68132 
Phillip Allendorfer 
402 423-1400 
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LOCAL USER GROUPS 


New England 

Northern: 

Meets monthly at different sites. 

• Peter Schmitt 603 646-2085 
Kiewit Computation Center 
Dartmouth College 
Hanover, NH 03755 
<peter.schmitt@dartmouth.edu> 

New Mexico 

Albuquerque: 

ASIGUNIX meets every 3rd 
Wednesday of each month. 

• Phil Hortz 505 275-0466. 

New York 

New York City: 

Meets every other month in 
Manhattan. 

• Uni group of New York City 
G.P.O. Box 1931 

New York, NY 10116 
<uniboard@unigroup. org> 

J. P. Radley 212 877-0440 

Oklahoma 

Tulsa: 

Meets 2nd Wednesday of each month. 

• Tulsa UNIX Users Group, $USR Bill 
Hunt 918 494-4848 
<bhunt@tulsix.utulsa.edu> 

Mark Lawrence 918 749-7498 
<lawrence@tulsix. utulsa, edu> 

Texas 

Austin: 

Meets 3rd Thursday of each month. 

• Capital Area Central Texas UNIX 
Society (CACTUS) 

P.O. Box 9786 
Austin, TX 78766-9786 
Ronald S. Woan 
512 838-1254 
<president@cactus.org> 

<http:i l cactus, org > 

Dallas/Fort Worth: 

Meets the 1st Thursday of each 
month. 

Dallas/Fort Worth UNIX Users Group 

P.O. Box 867405 

Plano, TX 75086 

Evan Brown 214 519-3577 

<e vbrown@dsccc. com> 


Houston: 

Meets 3rd Tuesday of each month. 

• Houston UNIX Users Group 
(Hounix) answering machine 
713 684-6590 

Jack Gilbert, President 
713 862-3637 
< jack@hounix. org> 

Washington 

Seattle: 

Meets monthly. 

• Seattle UNIX Group Membership 
Bill Campbell 206 947-5591 
6641 East Mercer 

Mercer Island, WA 98040-0820 
<bill@celestial. com> 

Canada 

Manitoba: 

Meets 2nd Tuesday of each month. 

• Manitoba UNIX User Group 
(MUUG) P.O. Box 130 

St. Boniface, Winnipeg, 

MB R2H 3B4 
Bary Finch, President 
204 934-1690 
<info@muug.mb.ca> 

Ottawa: 

• The Ottawa Carleton UNIX Users 
Group 

David J. Blackwood 
613 957-9305 
<dave@revcan.ca> 

Toronto: 

•143 Baronwood Court 
Brampton, Ontario 
Canada L6V 3H8 
Evan Leibovitch 
416 452-0504 
<evan@telly.on.ca> 

Quebec: 

Meets first Wednesday every 3rd 
month. 

• Administrateurs de Systeme 
UNIX du Quebec (ASUQ) 
University de Montreal, 

Dept. IRO 

C.P. 6128, Succ. Centre-Ville 
Montreal, Quebec, Canada, 

H3C 3J7 
514 343-7480 

<asuq @iro. umontrea l. com> 


System Administration 
Groups 

Back Bay LISA (bblisa) 

New England forum covering all aspects of 
system and network administration, for large 
and small installations. Meets monthly, at MIT 
in Cambridge, MA. 

For information, contact: 

• J. R. Oldroyd 617 227-5635 
<jr@opalxom> 

• Mailing list subscription: 
<bblisa-request@bblisa.org> 

• Mailing list postings: 

<bblisa@bblisa. org> 

• For current calendar of events: 
finger <bblisa@finger.bblisa.org> 

Bay USA (California) 

Meets 3rd Thursday of each month at Synop- 
sys in Mountain View, CA. For more informa¬ 
tion, please contact: <biw@baylisa.org> or 
<http:H www.baylisa.org> 

$GROUPNAME (New Jersey) 

SGROUPNAME is an organization in New Jer¬ 
sey formed to facilitate information exchange 
pertaining to the field of UNIX system admin¬ 
istration. For more information, send 
“infogroupname” to <majordomo@plts.org> 
Tom Limoncelli <tal@big.att.com> 

New York Systems 
Administrators (NYSA) 

Meets 2nd Monday of each month. 

• <nysa~request@esm.com> 

914 472-3635 or 472-3635 

North Carolina System 
Administrators Group 

The North Carolina System Administrators 
Group meets on the 2nd Monday each month 
around the Research Triangle Park area. 

• Amy Kreiling 919 962-1843 
<kreiling@cs.unc.edu> 

• William E. Howell 919 941-4868 
<william_howell@glaxo.com> 
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ACM: 

Association for Computing Machinery 


CALENDAR OF EVENTS 


This is a combined calendar of conferences, symposia, and stan¬ 
dards meetings. If you have a event that you wish to publicize, 
please contact <login@usenix.org>. 

* = events sponsored by the usenix Association. 


AFUU: 

Association of French UNIX Users 

ASPLOS: 

Architectural Support for Programming 
Languages and Operating Systems 

AUUG: 

Australian UNIX Systems Users Group 

COOTS: 

Conference on Object-Oriented 
Technologies 

DECUS: 

Digital Equipment Computer Users Society 

EurOpen: 

European Forum for Open Systems 

GURU: 

Romanian UNIX User Group 

GUUG: 

German UNIX Users Group 

IEEE: Institute of Electrical and 
Electronics Engineers 

IETF: 

Internet Engineering Task Force 

Interex: 

International Association of 
Hewlett-Packard Computer Users 

JUS: 

Japan UNIX Society 

USA: 

USE NIX/SAGE Systems Administration 
Conference 

OOPSLA: 

Object-oriented Programming 
Systems, Languages and Applications 

OSDI: 

Symposium on Operating Systems 
Design & Implementation 

ROSE: 

Open Systems in Romania 

SANS: 

System Administration, Networking 
& Security 

SIGPLAN: 

ACM Special Interest Group on 
Programming Languages 

SIGSOFT: 

ACM Special Interest Group on 
Software Engineering 

SOSP: 

ACM Symposium on Operating Systems 
Principles 

SUG: 

Sun User Group 

SUUG: 

Society of Russia UNIX Users Group 

UKUUG: 

United Kingdom UNIX Systems 
Users Group 

UniForum: 

International Association of 

UNIX and Open Systems Professionals 

Win: 

International Network of 
Women in Technology 
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1995 

August 

1-4 4th IEEE Int’l Symposium on High 
Performance Distributed 
Computing, Pentagon City, VA 

6-11 ACM SIGGRAPH, 

Los Angeles, CA 

13- 15 IEEE Hot Chips Symposium VII, 

Stanford, CA 

14- 18 Interex 95, Toronto, Canada 

September 

11- 13 EurOpen, Security Symposium 

Stockholm, Sweden 

12- 14 GUUG Annual Conference, 

Wiesbaden, Germany 
18-21 AUUG‘95, Sydney, Australia 

18- 22* LISA ‘95, Monterey, CA 
20-23 IEEE 4th Inti. Conf. Computer 

Communications & Networks, 

Las Vegas, NV 

19- 21 UNIX Expo, New York City 
25-29 Net World + Interop 95, 

Atlanta, GA 


1996 

January 

22-26* USENIX, San Diego, CA 

February 

14-16 UniForum, San Francisco, CA 

March 

IETF, Los Angeles, CA 

May 

13-17 SANS V, Washington, DC 
18-24 DECUS, Orlando, FL 

June 

1 - 6 DECUS, ‘96 St. Louis, MO 

August 

4 - 8 Interex ‘96, San Diego, CA 

September 

30-Oct4*LISA ‘96, Chicago, IL 

AUUG, Melbourne, Australia 


October 

16-20 IEEE 1003 
12-15 ACM SIGSOFT‘95, 

Washington, DC 

15-19 OOPSLA ‘95, Austin, TX 
25-28 IEEE Parallel & Distributed 
Processing, San Antonio, TX 
25-26 EurOpen, Publishing on Internet, 
Stockholm, Sweden 

November 

1 - 4 ROSE ‘95, Bucharest, Romania 
2-8 DECUS, San Francisco, CA 
6-10 NetWorld + Interop 95, Paris 

6- 10 IEEE Int’l. Conf. on Engineering of 

Complex Computer Systems, 

Ft. Lauderdale, FL 

7- 10 IEEE Int’l. Conf on Network Proto¬ 

cols, Tokyo,Japan 

December 

JUS UNIX Fair, Tokyo, Japan 
2.7 DECUS, San Francisco, CA 

3 - 6 SOSP, Colorado 

4 - 8 IETF, Dallas, TX 

4 - 8 ACM/IEEE-CS Supercomput¬ 
ing‘95, San Diego, CA 
11-14 4th World Wide Web 

Conference, Boston, MA 


Fall 

* 6th UNIX Security (date/1 oc.TBA) 

* COOTS (date/location TBA) 

October 

7- 11 ASPLOS (tentative) 

OOPSLA ‘96 

8- 10 UNIX Expo, New York City 
29- Nl* OSDI II, Seattle, WA 

November 

9-14 DECUS, Anaheim, CA 
18-22 ACM IEEE-CS Supercompu¬ 
ting ‘96, Pittsburgh, PA 

1997 

January 

6 - 10 * USENIX, Anaheim, CA 

March 

12-14 Uniforum, San Francisco, CA 

October 

27-31 * LISA ‘97, San Diego, CA 
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K-AShare/K-FS 

Share resources seamlessly 

Macintosh® and UNIX® workstation users share files effortlessly. K-A§hare™ ■' 
brings UNIX-resident files to Macintosh computers; K-FS™ brings Macintosh files 
to UNIX workstations. Cross-platform applications like Frame, Photoshop and 
Illustrator can read and write the same files from either system. 

Better than an AppleShare file server 

UNIX workstations running K-AShare provide higher performance than dedicated 
AppleShare servers while allowing Mac users to continue using the familiar Mac 
interface. 


And, the UNIX workstation simultaneously gets other important jobs done for you 


K-Spool 

More printing options 


1 Macintoshes and UNIX systems talk to all PostScript printers and image setters 
Jliet regardless of how they're connected. Each system continues to use its own 

560 9 tli St., #312 familiar printing interface. 


»erJ 


Leleij, CA 94710 


Increased productivity 



Macs finish printing more quickly, and UNIX workstations have access to many 
more printing devices. K-Spool also brings the power of SGI's Impressario™ to 
your Macs. 


FullPress 

Integrated prepress management system 

FullPress™ is the workflow solution to prepress file sharing, print spooling and 
OPI. affording increased productivity in prepress operations where multiple Macs 
are.used to produce complex pieces and imagesetting. 
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